6 ms·

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 highli

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 2y ago
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
- tschumacher 2y ago
  Interesting. I expected it to be near instant without syntax highlighting but it's still slow.
  - davorak 2y ago
    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
- j1elo 2y ago
  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 2y ago
    > 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.
goosejuice 2y ago
[dead]

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 2y ago

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

tschumacher 2y ago
Interesting. I expected it to be near instant without syntax highlighting but it's still slow.
- davorak 2y ago
  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
j1elo 2y ago
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 2y ago
  > 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.

goosejuice 2y ago

[dead]