大家好，新人第一帖，想了解一下各种编辑器的大文件支持。
我个人是深度的 VSCode 用户。很早以前被别人推荐过 EmEditor，说是大文件支持很好，正好 MDict 制作需要处理巨量的纯文本，希望在这里讨论这个问题。
除此之外在本坛也有看到命令行搜索替换和 FileLocator 之类的方案，都值得讨论讨论。
并不光是各种编辑器对大文件支持的情况，GUI 编辑器处理大文件的瓶颈是什么呢，EmEditor 为什么能做的很好？
edit 补充 wikien 上的 editor 对比
大文件的支持早先查过。
Nodepad++是2G，Ultraedit是4+GB，EmEditor是16TB。VSCode没查到数据，实际体验打开几百兆的文本都很困难。
这种都推荐用编程解决了，比如 python。至于 EmEditor 为什么擅长处理大文件，我想，这就是它的商业机密吧。
要批量处理或者要使用超过一次的才考虑编程解决吧，单纯改个小地方的话，没有 GUI 也顶多用 grep sed 之类的工具。
16T 也太离谱了，今天看到一个也把大文件处理当成强项拿出来说的也就 400G。
VSCode 打开稍大的文本就困难可能是因为各种插件、上色之类的功能吧，毕竟本来也不是做纯文本处理的。
我平常用的是 Notepad3，没有标注这方面的，不过应该也就 4G 上下，EmEditor 确实有点厉害了。
VSCode 是用 Electron 开发的，说白了就是浏览器包个壳，性能自然较差。其实 VSCode 已经算优化得不错了，在所有 Electron 程序里应该是优化得最好的之一，但是跟原生程序还是没法比。
瓶颈到底在哪，估计只有那几个作者才知道，从结果看，只有EmEditor解决了。
EmEditor 的确是最好处理的， 遗憾我使用的是macOS 暂不支持。 我暂时用 Vim 处理的 ，替换的时候用 sed 来全局替换的
sed -i .bak 's#<hr class="hrz">#<hr class="hrz"/>#g' concise_bing.xml
会先把concise_bing.xml 文件备份一下 ， # 也可以换成 /