第 1 条附言 · 18 天前
补充下：
1.文件大小 104M
2.17w 行 sql （我开始替换的是'
3.试过两个 notepad--和 uedit64
3.最后用 AI 写两个 py 的工具类
1.文件大小 104M
2.17w 行 sql （我开始替换的是'
3.试过两个 notepad--和 uedit64
3.最后用 AI 写两个 py 的工具类
第 2 条附言 · 18 天前
刚试了下 vscode 确实也很快。我用的编辑器问题吧
 |
1
agagega 18 天前
你没说是什么编辑器，也没说你的代码是怎么替换的。
一种可能是编辑器正则是 NFA ，也没考虑各种优化，刚好遇到文件里有大量回溯的情况。也有可能是编辑器渲染效率不行，替换后需要全部重绘，会卡很久。50M 这个级别，通常来说 Vim 和 Emacs 都没问题，VSCode 也不会有问题 |
 |
2
geelaw 18 天前
有很多可能的原因，比如编辑器打开文件时，替换的内容永远是正在编辑的版本，而不是磁盘上的版本，而多数文本编辑器会使用特别的数据结构存储打开的文档（按行断开、使用 rope 等等），相比磁盘上的文件被程序一口气读完、替换完、写完，编辑器内替换需要重新把数据结构转换为适合被正则表达式匹配的样子（替换完后再重新变成适合用来编辑的数据结构），或者使用针对该结构的匹配算法，然后还需要重新渲染等等。
当然， @agagega #1 指出的问题最明显，因为观众不可能有读心术~ 另 Re: #1 NFA 是抽象模型，和怎么实现没有必然联系，而且 NFA 最自然的实现也不用回溯。现代软件里的正则表达式也不是计算理论意义下的正则表达式，表达力强于 NFA 。 |
 |
3
Zaden 18 天前
有个重要原因是编辑器需要在内存中保存撤销记录，代码只要考虑顺序读写就行了
|
 |
4
flynaj 18 天前 via Android
这个快慢就是 GUI 程序的所见即所得决定的，内容每次改变都要刷新显示。所以就慢了，当然 50 兆这种大小现代编辑器都是秒完成的，我经常使用的是 emeditor
|
 |
5
alexsz 18 天前
用 sed 命令啊
|
Select Language