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