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