[silisili]

A few weeks ago I had this giant json text blob to debug. I tried Gedit first, and it just fell over completely. Tried vim next, and it was for some reason extremely slow too, which surprised me.

VSCode loaded it nearly immediately and didn't hang when moving around the file. I have my complaints about VSCode, but speed definitely isn't one of them.

[angra_mainyu]

For this kind of stuff Sublime has always been extremely good.

But I still struggle to find a reason to not use neovim, it's replaced all my editors.

[nicce]

Did you have some plugins in vim? It is very odd if it was slower in this scenario.

[silisili]

Not to my knowledge, outside of whatever Debian comes with. Keep in mind this was on a Chromebook - so it would have been running in a VM on a rather memory restricted system. That said, VSCode would have been running in the same parameters.

Just found the file. 42MB on a single line. Takes 5 seconds to open in vim, and about 3 seconds for the right arrow to move the cursor one char over. Nothing like gedit, but slower than I expected.

[tschumacher]

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'

[silisili]

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

[j1elo]

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

[maccard]

> 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.

[tschumacher]

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

[davorak]

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

[crabbone]

> 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.

[maccard]

> 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.

[nicce]

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.

[nicce]

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

[silisili]

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

[nicce]

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.

[iso8859-1]

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

[satvikpendem]

Weird, I had the exact opposite experience. I had a large Markdown file I was editing and VSCode would simply hang or crash when opening it. Neovim on the other hand actually was able to navigate and edit just fine.

[wraptile]

I work with giant jsons every day and always have to fall back to nvim as vscode is terrible. Vscode even has a default size limit where it disables editor features for json files larger than a few megabytes.

Nvim works flawlessly tho even with syntax highlight and folding.

[ThinkBeat]

I believe VsCode has told me several times that the file i want to open is too big.

[tills13]

It's more of a suggestion/question than a hard limit though, no? "Are you sure you want to open this 4GB file?"