Ubuntu中文论坛

刚刚试了一下 EMACS 和 GVIM 在 WINDOWS XP 下打开 大文件的速度：
文件名字是 管理励志系列合集.chm 103MB
所用字体是 Envy Code R 10号字

结果，EMACS 用了3秒， GVIM 用了2秒。
打开后，EMACS 显示的是 \242\230\235 一类， 试了下上下移动光标，如果是一下一下的按键，没怎么感觉延迟；但是如果是一直按着不放，比如 C-N， 就延迟很厉害，光标死在那里，过了一阵子才能直接跳到该在的位置。
而 GVIM 显示的是 ^@^A^D 一类， 同样上下移动光标，在一下一下的按键时，也没有延迟；一直按着不放， 比如 j， 同样没有延迟。

再次测试：在同样的情况下，打开一个 RAR 压缩文件， EMACS 就 !MEM FULL 了，自然就没有打开。 GVIM 用了4秒，但是打开了文件，显示乱码（这是当然的），光标移动没有延迟，一直按键也同样没有延迟。

为什么 EMACS 打开大文件就这么慢， 以至于无法打开？ 是 ELISP 的问题么？

你找个单行的 >10M 的 XML 文件在 Vim 里打开试试？

ChenFengyuan 写了：http://www.emacswiki.org/emacs/vlf.el

相当于是说，EMACS 在缺省状态下无法打开大文件，或者很容易挂掉？
必须加个 addon 才行？

这也太那个啥了吧？

我没找到一行10MB 的XML 文件。

但是我搞了个替代的，也可以说明一些问题。

我把 Emacs23.tar.bz2 共 32.7 MB，改了后缀名为 .t, 这样用 2 种编辑器打开时就是二进制那种了。

因为对 GVIM 熟悉点， 在 GVIM 中不停的连接2行， 按键如下：
100J
直到 GVIM 反应明显迟钝为止。然后保存为 1.t。 这样这个文件的第一行就很长了。估计没有 10MB.

然后再分别用 EMACS 和 GVIM 打开， 按住左右光标键不放，看看效果。结果 GVIM 行动自如，但是 EMACS，光标还是卡住，直到放手后1秒左右才出现在新的位置（我也不知道这个位置对不对）。

就这一行，VIM 好歹还能左右移动光标， EMACS 还是一样挂了。

看来不需要你那种XML测试了，因为还有颜色高亮的问题，估计到时候 EMACS 更慢。

1、关掉所有插件看看能改善么。
2、 CPU好的话，重下源代码自己开SSE4.2编译次看看有改善否。

jameschyn 写了：我没找到一行10MB 的XML 文件。

但是我搞了个替代的，也可以说明一些问题。

我把 Emacs23.tar.bz2 共 32.7 MB，改了后缀名为 .t, 这样用 2 种编辑器打开时就是二进制那种了。

因为对 GVIM 熟悉点， 在 GVIM 中不停的连接2行， 按键如下：
100J
直到 GVIM 反应明显迟钝为止。然后保存为 1.t。 这样这个文件的第一行就很长了。估计没有 10MB.

然后再分别用 EMACS 和 GVIM 打开， 按住左右光标键不放，看看效果。结果 GVIM 行动自如，但是 EMACS，光标还是卡住，直到放手后1秒左右才出现在新的位置（我也不知道这个位置对不对）。

就这一行，VIM 好歹还能左右移动光标， EMACS 还是一样挂了。

看来不需要你那种XML测试了，因为还有颜色高亮的问题，估计到时候 EMACS 更慢。

我的意思是说，Vim 的语法高亮（正则）处理非常慢。

打开大的二进制文件为什么不用二进制编辑器，打开大的log文件为什么不用less？

我用的都是缺省 EMACS ,GVIM 做测试的, 我只是把二者的字体改成了 Envy Code R, 其他的什么插件的，都没有自行添加。

我并不是要编辑二进制文件，我只是想要个大文件。在这个意义上，他们都是文件，都是可以用十六进制表示的。即便是 文本文件，也一样可以显示成 /205/220/210 一类的。 所以在这一点上是没有差别的。

用less只能看，不能修改。如果我有一个大型的文本文件可能需要修改，就只能用编辑器。这是我做这个对比测试的原因。

这个测试只是要对比 2 个编辑器，不涉及怎样打开一个大文件的问题。 就不要提使用外部工具了(less一类)。

jameschyn 写了：我用的都是缺省 EMACS ,GVIM 做测试的, 我只是把二者的字体改成了 Envy Code R, 其他的什么插件的，都没有自行添加。

我并不是要编辑二进制文件，我只是想要个大文件。在这个意义上，他们都是文件，都是可以用十六进制表示的。即便是 文本文件，也一样可以显示成 /205/220/210 一类的。 所以在这一点上是没有差别的。

用less只能看，不能修改。如果我有一个大型的文本文件可能需要修改，就只能用编辑器。这是我做这个对比测试的原因。

这个测试只是要对比 2 个编辑器，不涉及怎样打开一个大文件的问题。 就不要提使用外部工具了(less一类)。

这样的测试没有意义，仅仅是默认配置emacs不见得好用，emacs的长处是把所有的东西都配置齐了才好用，非要在缺省配置下用emacs然后企图得出emacs不能打开大文件，emacs不能干这不能干那的结论是毫无意义的，没有谁不配置emacs而使用的，除非蛋疼。
另外你找的那也不算什么大文件，如果你真的有大型文件要修改，应该用ed而不是什么vi/emacs。

josephyoung 写了：

jameschyn 写了：我用的都是缺省 EMACS ,GVIM 做测试的, 我只是把二者的字体改成了 Envy Code R, 其他的什么插件的，都没有自行添加。

我并不是要编辑二进制文件，我只是想要个大文件。在这个意义上，他们都是文件，都是可以用十六进制表示的。即便是 文本文件，也一样可以显示成 /205/220/210 一类的。 所以在这一点上是没有差别的。

用less只能看，不能修改。如果我有一个大型的文本文件可能需要修改，就只能用编辑器。这是我做这个对比测试的原因。

这个测试只是要对比 2 个编辑器，不涉及怎样打开一个大文件的问题。 就不要提使用外部工具了(less一类)。

这样的测试没有意义，仅仅是默认配置emacs不见得好用，emacs的长处是把所有的东西都配置齐了才好用，非要在缺省配置下用emacs然后企图得出emacs不能打开大文件，emacs不能干这不能干那的结论是毫无意义的，没有谁不配置emacs而使用的，除非蛋疼。
另外你找的那也不算什么大文件，如果你真的有大型文件要修改，应该用ed而不是什么vi/emacs。

用ed也不行。如果有个超过内存大小的文件，你照样不能用ed编辑
编辑一个n M的文件，ed需要3n~4nM的内存。
比如我打开个100M的ascii文件
ed用了352MB内存。
vim用了142MB内存.
emacs用了118MB内存

ChenFengyuan 写了：

josephyoung 写了：

jameschyn 写了：我用的都是缺省 EMACS ,GVIM 做测试的, 我只是把二者的字体改成了 Envy Code R, 其他的什么插件的，都没有自行添加。

我并不是要编辑二进制文件，我只是想要个大文件。在这个意义上，他们都是文件，都是可以用十六进制表示的。即便是 文本文件，也一样可以显示成 /205/220/210 一类的。 所以在这一点上是没有差别的。

用less只能看，不能修改。如果我有一个大型的文本文件可能需要修改，就只能用编辑器。这是我做这个对比测试的原因。

这个测试只是要对比 2 个编辑器，不涉及怎样打开一个大文件的问题。 就不要提使用外部工具了(less一类)。

这样的测试没有意义，仅仅是默认配置emacs不见得好用，emacs的长处是把所有的东西都配置齐了才好用，非要在缺省配置下用emacs然后企图得出emacs不能打开大文件，emacs不能干这不能干那的结论是毫无意义的，没有谁不配置emacs而使用的，除非蛋疼。
另外你找的那也不算什么大文件，如果你真的有大型文件要修改，应该用ed而不是什么vi/emacs。

用ed也不行。如果有个超过内存大小的文件，你照样不能用ed编辑
编辑一个n M的文件，ed需要3n~4nM的内存。
比如我打开个100M的ascii文件
ed用了352MB内存。
vim用了142MB内存.
emacs用了118MB内存

听您说我试了一下，同样打开22M的文件，vim用的内存33M，ed用的内存4812K。
不知道您用的ed是为什么要占用那么多内存呢？或者我理解错了？top这个RES应该是物理内存占用吧

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5715 joe 20 0 8748 4812 640 S 0 0.2 0:00.56 ed
5717 joe 20 0 40344 33m 2228 S 0 1.7 0:00.65 vim

难道是我弄错了？百十 M 的就叫大文件？
ok，100G的文本文件，给点建议