关于编辑器的大文件支持

软件经验交流展望
1

大家好，新人第一帖，想了解一下各种编辑器的大文件支持。
我个人是深度的 VSCode 用户。很早以前被别人推荐过 EmEditor，说是大文件支持很好，正好 MDict 制作需要处理巨量的纯文本，希望在这里讨论这个问题。
除此之外在本坛也有看到命令行搜索替换和 FileLocator 之类的方案，都值得讨论讨论。
并不光是各种编辑器对大文件支持的情况，GUI 编辑器处理大文件的瓶颈是什么呢，EmEditor 为什么能做的很好？
edit 补充 wikien 上的 editor 对比

2

大文件的支持早先查过。

Nodepad++是2G，Ultraedit是4+GB，EmEditor是16TB。VSCode没查到数据，实际体验打开几百兆的文本都很困难。

3

这种都推荐用编程解决了，比如 python。至于 EmEditor 为什么擅长处理大文件，我想，这就是它的商业机密吧。

4

要批量处理或者要使用超过一次的才考虑编程解决吧，单纯改个小地方的话，没有 GUI 也顶多用 grep sed 之类的工具。

1 个赞
5

16T 也太离谱了，今天看到一个也把大文件处理当成强项拿出来说的也就 400G。
VSCode 打开稍大的文本就困难可能是因为各种插件、上色之类的功能吧，毕竟本来也不是做纯文本处理的。
我平常用的是 Notepad3，没有标注这方面的，不过应该也就 4G 上下，EmEditor 确实有点厉害了。

6

VSCode 是用 Electron 开发的，说白了就是浏览器包个壳，性能自然较差。其实 VSCode 已经算优化得不错了，在所有 Electron 程序里应该是优化得最好的之一，但是跟原生程序还是没法比。

1 个赞
7

瓶颈到底在哪，估计只有那几个作者才知道，从结果看，只有EmEditor解决了。

1 个赞
8

EmEditor 的确是最好处理的， 遗憾我使用的是macOS 暂不支持。 我暂时用 Vim 处理的 ，替换的时候用 sed 来全局替换的

sed -i .bak 's#<hr class="hrz">#<hr class="hrz"/>#g' concise_bing.xml

会先把concise_bing.xml 文件备份一下 ， # 也可以换成 /

1 个赞