实在想不通为什么 Windows 记事本打开大文件比 VS Code 慢那么多

szzhiyang 16天前 23


同一份 100MB 的纯文本文件,VS Code 只用一两秒就打开完成了,记事本卡了一分多钟都还不见一个字。


VS Code 是用以慢著称的 Electron 框架写的,记事本是用以快著称的 C++ 写的,可为什么后者打开文件反而更慢并且还慢那么多呢?


最新回复 (40)
  • wangkun025 12天前
    引用 2
    占用资源多,干的事儿多。
  • LokiSharp 12天前
    引用 3
    记事本是整个 100M 读到内存并渲染的,VSCode 是一块一块逐步读取渲染。类似的可以了解一下低速网络环境下浏览器如何加载大型 HTML 页面
  • Mohanson 12天前
    引用 4
    vscode 有官方文章介绍大文件这件事,可以搜搜看看,逐步渲染和整体渲染的区别,楼主如果是前端的话这些知识还是要掌握的,引战没意思。
  • lower 12天前
    引用 5
    钓鱼?
  • aoeui 12天前
    引用 6
    记事本只能打开 64 KB 的内容
  • xJogger 12天前
    引用 7
    自行车骑上就能走,最多去附近买个菜。
    汽车要发动一会才能走,想跑个几十公里没啥问题。
    开汽车去附近买菜大家觉得没必要,但用自行车起个几十公里,一般人也会觉得没啥必要。
  • yyfearth 12天前
    引用 8
    这个读取超大文件本就好什么框架或者什么语言编写没关系
    必须要做到按需读取部分文件和渲染来做到

    记事本要完全读取文件 并且完全渲染才会显示出来 自然要慢
    VSCode 和专业一些的编辑器会支持这种大文件读取 自然就不会太卡
  • edk24 12天前
    引用 9
    记事本完整读取文件到内存

    编辑器有可能是用 fopen() fread() fclose() 用偏移来读取, 不用完整读取到内存中, 只需要按偏移截取部分

    这个是我的理解, 嘿嘿
  • koharu 12天前
    引用 10
    你可以对比两个软件打开文件后拖动进度条的感受
  • reus 12天前
    引用 11
    想不通就多学习,肤浅
  • luckyrayyy 12天前
    引用 12
    记事本本来就不是干这个用的....c++写的就代表性能碾压一切了?
  • maokabc 12天前
    引用 13
    不是文件读取问题,读取文件那点时间差异可以忽略不计,主要在文字排版和渲染。vscode 用的数据结构是改进过的 piece table,也是一次性完全读取文件,不是编辑几 g 那种大文件没必要部分加载。
  • Luoboaibaicai 12天前
    引用 14
    可能是该换电脑了吧
  • will0404 12天前
    引用 15
    我也记得 vscode 是改进的渲染部分,读文件仍然是一次 io 全部读取的。
  • okjb 12天前
    引用 16
    回楼上
  • stevenhawking 12天前
    引用 17
    vscode 是测算你一屏幕会阅读到哪一段落,只读取和渲染那一段落;
    notepad 是哪怕是个蓝光 avi 也要全部读取
  • jrtzxh020 12天前
    引用 18
    @okjb 发傻了?自言自语 !
  • gainsurier 12天前
    引用 19
    最快的还是 emeditor,十几 G 的文件轻松读取。
  • wangkun025 12天前
    引用 20
    @gainsurier 比 sublime 厉害吗?
  • wee911 12天前
    引用 21
    vscode 很多都是 c++写的,就视图用了下 electron
  • SpiderZzx 12天前
    引用 22
    还记得小时候网速慢看那种颜色网站图片和网页都是一点一点慢慢加载出来的
  • zdnyp 12天前
    引用 23
    好重的的戾气...
  • gitopen 12天前
    引用 24
    打开 GB 级别的 txt,mac 上,速度 UltraEdit > sublime > vscode
  • ungrown 12天前
    引用 25
    @zdnyp #22 没闻到,大家对“戾气”“杠精”这类词真的喜欢随性滥用
  • ysc3839 12天前
    引用 26
    印象中记事本是把文件映射到内存,再把指针传给 Edit 控件。而 Edit 控件会读取全部数据,不会分段读取。
    具体情况如何还得逆向以及看看 ReactOS 的实现。
  • imn1 12天前
    引用 27
    vscode 是异步读取的吧?
  • linvon 12天前
    引用 28
    @jrtzxh020 这是个梗
  • hjahgdthab750 12天前
    引用 29
    @aoeui 什么意思?
  • liuzhiyong 12天前
    引用 30
    你用 UltraEdit 试试:记事本和 VSCode 不是一个级别的工具。
  • cheng6563 12天前
    引用 31
    windows 原生的古董控件是这样的。
  • GrayXu 12天前
    引用 32
    自己想想如果自己写一个读大文件的,会怎么写,就知道他们的区别了
  • stephenyin 12天前
    引用 33
    内存映射了解一下
  • laqow 12天前
    引用 34
    C++什么时候快过?
  • xiaoming1992 12天前
    引用 35
    @jrtzxh020 一看就不怎么逛 b 乎。。。
  • daozhihun 12天前
    引用 36
    sublime 打开大文件貌似更快
    记得以前有个微软的人说他们也很惊讶 sublime 为什么能那么快
  • lonewolfakela 12天前
    引用 37
    记事本可以正确显示各种奇葩文字,横着的竖着的叠着的左右横跳的……相比之下 vscode 弄了快四年都弄不好 RTL (由右至左的文字)支持( https://github.com/microsoft/vscode/issues/11770 )。
    然而 vscode 作为代码编辑器,主要还是把 ASCII 码文字正确显示就能完成其主要功能了。而记事本作为一个系统的默认的基本文本编辑器,用户会用它来查看各种各样的语言和内容的文档,所以支持各种语言都是有必要的。
    所以记事本速度慢实在是很正常的事情,毕竟要支持这些奇怪的东西都是有代价的。
  • mostkia 12天前
    引用 38
    记事本是将整个文件读取到内存的,并且修改也是刷新整个内存数据的,你打开一个 10M 的文档,可以试着在开头插入一个字符串,看看计算机是不是会卡死一段时间
  • codehz 12天前
    引用 39
    @lonewolfakela #36 然后记事本还是不支持彩色 emoji...
    这玩意就是 edittext 控件的试验场,哪里来的这么多操作。
  • shuax 12天前
    引用 40
    记事本没优化
  • lxilu 12天前
    引用 41
    @codehz #38 反过来说,Chromium 不支持文本样式。老 Edge 和 Firefox 支持 emoji-specific variation selectors.
  • 游客
    42
返回