I'm pretty sure this is syntax highlighting. It's a known issue to be slow for large files in Vim because it is synchronous. Try starting Vim with syntax highlighting off:

    vim -c 'syn off'

Yep that helps a ton, thanks. Now it behaves more like nvim, and cursors around much faster -

$ time vim -c 'syn off' tt.json

real 0m3.277s user 0m1.690s sys 0m0.349s

This makes sense. I recently learned that VSCode is clever enough to automatically disable some features (which includes syntax highlighting among I guess other things) when it detects that the file is too big according to some heuristics (like probably, length of the longest line, or maybe just total size of the file).

So IMO I think vim is being "too dumb" here and should be able to adapt like VSCode does. But, meanwhile, if you want to test under equal conditions, you can disable VSCode's optimization by disabling this setting:

Editor: Large File Optimizations

Or directly in settings.json:

    "editor.largeFileOptimizations": false

> But, meanwhile, if you want to test under equal conditions, you can disable VSCode's optimization by disabling this setting:

Disabling the advantages of one application vs another is just kneecapping the superior editor IMO.

Interesting. I expected it to be near instant without syntax highlighting but it's still slow.

It is odd that it is slow. On my 2019 macbook pro

edit

new more realistic example: time vim -c 'syn off' <64 MB>.txt vim -c 'syn off' <64 MB>.txt 0.41s user 0.20s system 32% cpu 1.848 total

---

Here is my first, pre edit, example which is invalid. The file was a zip and my install of vim was not opening as text or binary

% time vim -c 'syn off' <48 GB file> vim -c 'syn off' <48 GB file> 0.03s user 0.03s system 2% cpu 2.380 total

Just curious, what of you do the same with bare neovim, for science?

Sure, just tried it. This is time to open, show the initial contents, then exit. nvim is much faster to cursor around, except when you hit the opening or closing of a json block it hangs a bit, so I'm guessing it has some kind of json plugin built in.

$ time vim tt.json

real 0m5.910s user 0m4.120s sys 0m0.343s

$ time nvim tt.json

real 0m2.894s user 0m1.372s sys 0m0.292s

I did some research and it seems that this particular slowness is due to single line file and if there is some syntax highlighting used with vim/neovim, it reads the line completely to do it correctly.

VSCode reads only the visible content and does not load everything for that line. It tokenizes the first 20k chars of the line at maximum, defined by the "editor.maxTokenizationLineLength" setting.

Might want to try https://github.com/LunarVim/bigfile.nvim

> on a single line

This makes a world of a difference when your editor is configured to wrap lines, or clip or w/e.

You probably happened to have VSCode configured to do something that mitigates the problems of having an extremely long single line, while Vim was not configured to do that.

In case you don't want to investigate the problem, but want to make a more "fair" comparison: use a language that you are comfortable with to format the file with linebreaks and indentation and then load it in different editors.

> You probably happened to have VSCode configured to do something that mitigates the problems of having an extremely long single line, while Vim was not configured to do that.

Defaults matter.

For mainstream users. Particularly in the case of vim, the end-user is more likely the figure out that this is a configuration problem and can be adjusted.