This repository has been archived by the owner on Apr 16, 2024. It is now read-only.
doom: disable slow features on large files #416
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Checking lua/doom/modules/features/lsp/init.lua 1 warning
lua/doom/modules/features/lsp/init.lua:214:9: unused variable source_map
Checking lua/doom/modules/langs/cc/init.lua 1 warning
lua/doom/modules/langs/cc/init.lua:1:7: unused variable utils
Signed-off-by: Edwin Török <edwin@etorok.net>
Use LargeFile.vim to disable syntax highlighting on large files. Gitsigns and treesitter cna also be very slow on large files (e.g. gigabytes of logfiles), so disable these as well. By default a file is considered "large" if it either exceeds 10000 lines, or 1MiB. The linecount is not known when first opening the buffer, hence the need for a file size limit too. Signed-off-by: Edwin Török <edwin@etorok.net>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I regularly have to open files that are gigabytes in size (logfiles), or source code that contains hundreds of thousands of lines, in which case Neovim can hang for a long time on opening the file, and every action inside the file is very very slow (moving lines takes several seconds).
Some of the features which become very slow on large files include:
Since Doom-nvim is focused on performance I think it'd be appropriate to have a feature to deal with large files better.
It won't be pretty, but at least the file will open and you can edit it.
If I have time I can take a look at more gradual disabling of features (e.g. maybe treesitter highlighting itself is not too bad, it is just all the tree-sitter plugins that are very slow on large files), but meanwhile this might be useful for someone already.
I also have some scripts that can measure performance using
hyperfineand some simple scenarios (e.g. fabricate a "large" file with thousands of lines and measure how long it takes to use a motion to go to the end and insert some characters). These scenarios are more than just the usual "vim startup time", which although important may miss the point in some cases: I think what matters is "time to first action" (similarly to how browser latency is sometimes measured as 'time to first byte'): if my editor is frozen for minutes and won't respond to anything I type when I open a file, then the fact that the editor "started up" in 10ms or 100ms matters little, what should be measured is how soon before the editor is able to receive user input. (And then all else being equal, a faster startup "display" time is of course desirable).The scripts aren't quite finished yet, so they are not included in this PR. You can see their current state at https://github.com/edwintorok/doom-nvim/blob/main/tools/profileit.sh and https://github.com/edwintorok/doom-nvim/blob/main/tools/compare_perf.sh.
It is a bit tricky to automate bootstrapping of neovim from 2 different commits to compare performance in a reproducible way, and I don't currently have a way to automatically check whether bootstrapping of doom succeeded or not, if it hasn't then it'll print various warnings/errors and not initialize completely which will cause any performance comparisons to be invalid.
What do you think?