这里有人知道编辑器在大文件中搜索和替换所需的资源吗？我问的原因是我有一台 32 核服务器HTOP仅显示一当使用编辑器搜索/替换 3GB 文件时，核心处于 100%。我想知道我的编辑器搜索/替换是否是单线程的，如果是，是否有办法委派更多资源，以便这些任务不会花费这么长时间？我不得不说，当一项任务需要 25 到 30 分钟时，看到 31 个空闲核心和 1 个 100% 运行是令人沮丧的。
哦，如果有什么区别的话，RAM 是 32GB，包括缓存在内，已使用 19GB。
答案1
编辑器可能是多线程的，也可能不是，但是，即使是多线程的，也不太可能将线程用于此目的，原因很简单：这样做不会为规范使用，这无疑会给开发人员带来麻烦，并可能会损害一些功能是被认为重要（用于规范使用）。
考虑到无限量的时间和无限数量的程序员，毫无疑问，所有软件都会被疯狂地优化到最小的、最不相关的细节，并进行广泛的测试以确保这些优化不会对任何事情产生负面影响，等等。没有人愿意花时间编写 99.9% 的用户永远不会欣赏的功能，特别是如果 0.1% 的用户这样做是因为（打个比方）他们真的想用锤子打开汤罐头。
正如一些人指出的那样，将 3 GB 文件加载到文本编辑器中进行搜索和替换是很好的，如果仅有的您知道如何进行搜索和替换的方式是在文本编辑器中。顺便说一句，我并不是想以此来侮辱你，只是给你一个友好的推动——现在是时候拓宽视野了；）
答案2
最有可能的是，编辑器是单线程的。您最好将文件分成 32 个部分，然后使用 perl 或 sed 等工具来搜索和替换。
答案3
查看sed流编辑器。它有一个类似于 的命令集vi，但不会读入文件来处理它，它一次读取、修改和写出一行（大多数情况下，请查看手册）。所以你至少可以减少读入文件（编辑器必须构建复杂的内存数据结构）然后写出来所需的时间。
[我对当前一批编辑器能够处理此类文件感到（并不那么）惊讶，我清楚地记得原始版本vi在处理几十 KiB 大小的文件时严重崩溃......原文如此，transit gloria mundii。]
答案4
对于任何编辑者来说，搜索和替换超过 3GB 的文本都是一项艰巨的任务。我认为最好的解决方案是使用珀尔。您可以使用珀尔自动将文件分成更小的部分，并在每个部分上并行运行正则表达式。有很多方法可以将其编码到 Perl 中。稍后我会发布一个例子。