Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nvim cpu 100% when I modify a 800k config #13

Closed
fcying opened this issue Sep 25, 2021 · 1 comment
Closed

nvim cpu 100% when I modify a 800k config #13

fcying opened this issue Sep 25, 2021 · 1 comment

Comments

@fcying
Copy link

fcying commented Sep 25, 2021

after enable cmp-buffer, when I modify a 800k config file is very slow. nvim cpu is 100%

nvim Corefile
o
.5  #cpu 100%

Corefile.zip

@dmitmel
Copy link
Collaborator

dmitmel commented Nov 18, 2021

The problem here is that the file has a very very long line which is slightly larger than 800 kilobytes, containing most of its content. This essentially freezes buffer:index_line. I have tried adding a fallback implementation which switches to vim.fn.matchstrpos on very long lines because that function has a start index argument and so doesn't require repeatedly slicing a string (but has to be used as a fallback because of the cost of calling into Vimscript functions, so on typical files it is considerably slower than vim.regex:match_str), but that doesn't seem to be much of an improvement, most likely because Lua strings have to be recopied as Vimscript strings. I think this is a good argument in favor of introducing an option like max_line_length which would set the max number of characters (not bytes since blindly slicing on bytes can create invalid UTF from multibyte characters) in a line which will be used by the indexer, and setting it to something like 40 kilobytes by default. I can make a PR.

@dmitmel dmitmel closed this as completed in f83773e Jan 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants