3

我正在尝试在 Windows 上的 gvim 中打开一个 200MB 的文本文件，结果令人窒息。vim 窗口打开并保持空白且无响应。我的系统有 8GB 的​​ RAM，使用记事本在大约 2-5 秒内打开文件。

我发现这篇关于在 vim 中编辑非常大的文本文件的 SO 帖子，我尝试在关闭插件的情况下打开文件：

vim -u "NONE" my200MBfile.text

但这没有帮助。我还能做些什么来让它发挥作用吗？奇怪的是，vim 会在我的机器上阻塞实际上不是那么大的文件。

谢谢！

4

3 回答 3

7

很可能是使 vim 停止的语法插件。我对 Mbs-Gbs 文件从来没有任何问题。除非我不小心用一些不那么好的文件类型打开它们。

加载/挂起时按 ^C（中断插件）

:syntax off

行得通。还有其他语法选项可以更轻松地处理文件而无需完全“同步”语法突出显示

我又玩了一些，我发现我的一些插件确实会使对（非常）大文件的操作非常慢。我这样做是为了好玩：

在大型输入文件（~600Mb）上：

$ wc input.txt.full 
  2674568   2674568 608825278 input.txt.full

我通过以下调整启动了 vim：

vim -u NONE -n +'se nonu nowrap ul=-1 | syn off' input.txt.full

注意这个

  • -u NONE阻止执行初始化（用户）脚本和插件
  • -n禁用交换文件的写入（在慢速/小型磁盘上非常重要）

  • se nonu nowrap ul=-1禁用

    • 行号
    • 换行
    • 撤消历史记录（设置undolevels为负值）

    基本上，所有可能占用大量 CPU 或内存的东西

  • syn off禁用语法高亮（仅当语法高亮对文件类型有效时才会有所不同）

现在，我想复制行本身的每一行（全局：复制行，与上一个连接）：

:g/^/t.|-j

不幸的是，文件对于可用内存 (~3Gb) 1来说太大了，所以我选择对前 20%（~535,000 行）采取行动：

:exec "norm 20%"|1,.g/^/t.|-j

这可以“快速”工作并且没有问题。手动导航（跳跃、滚动、模式切换、搜索等）似乎反应灵敏。

命令行基准：

$ xxd -c 44 /dev/urandom | head -n 3800000 >  input.txt.full 
$ wc input.txt.full 
  3800000  91820644 627000000 input.txt.full
$ time vim -u NONE -n +'se nonu nowrap ul=-1 | syn off' input.txt.full +'exec "norm 10%"|1,.g/^/t.|-j' +wq

real    0m7.778s
user    0m6.680s
sys 0m0.952s

$ wc input.txt.full 
  3800000 101002757 689940307 input.txt.full

（请注意689940307 ÷ 627000000 = 110.03 %，这是完全正确的）。

这在我的书中并不慢。作为比较，wc调用本身 需要相同的时间（7.7 秒）。

1执行所有测试tmpfs以避免缓存差异。

于 2012-11-14T19:05:52.207 回答
5

问题更可能是 vim 不喜欢那么长的行。

首先尝试使用json_reformat文件上的工具...

如果您绝对必须按原样编辑文件，请尝试:syntax off并可能:set nowrap在您:edit有问题的文件之前尝试。

于 2012-11-14T18:58:36.610 回答
2

尽管 Vim 打开该大小（或更大）的文件没有问题，但有人提到它在打开文件时遇到问题，就像您的情况一样，只有一行（该大小）。

您可以尝试各种解决方法，但我建议使用“正确工作的正确工具”方法，并尝试EmEditor，这是一个专门用于编辑大文件（以及其他内容）的文本编辑器。

请注意，这不是对 Vim 的抨击，而是 Vim 是一个主要用于编辑源代码的编辑器。在这方面非常出色，但与其他所有工具一样，它也有其局限性。

于 2012-11-14T20:40:35.077 回答