2 ms·
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.69
by 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 agoInteresting. I expected it to be near instant without syntax highlighting but it's still slow.
- davorak 2y agoIt 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 agoThis 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.