Closed bo5o closed 1 year ago
I narrowed down the issue. Disabling treesitter for python solves the problem.
FUNCTIONS SORTED ON TOTAL TIME
count total (s) self (s) function
1 0.048810 0.000128 ale#fix#ApplyFixes()
1 0.048475 0.007672 ale#fix#ApplyQueuedFixes()
9 0.038978 0.000405 ale#python#FindExecutable()
9 0.038371 0.020308 ale#python#FindVirtualenv()
1 0.035338 0.000046 ale#Queue()
1 0.034697 0.000035 ale#engine#RunLinters()
3 0.018789 0.000359 ale#engine#HandleLoclist()
1 0.016812 0.000100 ale#events#SaveEvent()
1 0.016632 0.000219 ale#fix#Fix()
1410 0.015747 ale#path#Simplify()
3 0.015342 0.000426 ale#engine#SetResults()
5 0.014710 0.001102 ale#command#Run()
3 0.013986 0.000035 ale#linter#GetCommand()
5 0.010455 0.010424 ale#job#Start()
3 0.010333 0.000072 ale_linters#python#flake8#GetExecutable()
3 0.010298 0.000047 ale#linter#GetExecutable()
1 0.010229 0.000115 ale#fixers#black#Fix()
1 0.010024 0.000052 ale#fixers#black#GetExecutable()
1 0.007035 0.000028 ale_linters#python#flake8#RunWithVersionCheck()
3 0.007032 0.000041 ale#semver#RunWithVersionCheck()
I posted the issue on nvim-treesitter/nvim-treesitter
This seems related to #3634 but so far no viable workaround has been found AFAIK. That issue mentions very large files but this case is not that big and your investigation seems to indicate treesitter may have something to do with the slowness. Thanks for reporting.
Just to mention that this happened to me with Javascript using eslint_d
. The file is not that big (only 159 lines). Disabled treesitter and works like a charm again!
Can someone test if the following patch fixes that performance problem. I haven't yet been able to reliably reproduce the performance issue on my system, otherwise I would test it myself (alternatively provide me a complete file where you can reproduce the performance problem).
0001-Avoid-performance-problems-with-setbufline-and-Trees.patch.txt
Also available at https://github.com/vimpostor/ale/tree/slow_fixer
This uses nvim_buf_set_lines()
instead, which should be faster.
If this does indeed improve performance, I can create a PR (I have to test some edge cases first), so I'd appreciate it if someone could test this. :)
Here are my results.
FUNCTION ale#util#SetBufferContents()
Defined: ~/.local/share/nvim/plugged/ale/autoload/ale/util.vim:503
Called 1 time
Total time: 1.452711
Self time: 0.135938
...
1 0.000001 if l:has_bufline_api
1 1.450276 0.135625 call setbufline(a:buffer, 1, l:new_lines)
1 0.002391 0.000272 call deletebufline(a:buffer, l:first_line_to_remove, '$')
" Fall back on setting lines the old way, for the current buffer.
FUNCTION ale#util#SetBufferContents()
Defined: ~/.local/share/nvim/plugged/ale/autoload/ale/util.vim:503
Called 1 time
Total time: 0.017660
Self time: 0.008204
...
1 0.000001 if l:has_bufline_api
1 0.000003 if has('nvim')
1 0.017605 0.008151 call nvim_buf_set_lines(a:buffer, 0, l:first_line_to_remove, 0, l:new_lines)
else
call setbufline(a:buffer, 1, l:new_lines)
call deletebufline(a:buffer, l:first_line_to_remove, '$')
1 0.000001 endif
" Fall back on setting lines the old way, for the current buffer.
Overall speedup as expected. This has been mentioned here as well: https://github.com/nvim-treesitter/nvim-treesitter/issues/1118#issuecomment-873658538
EDIT: Added git commit hashes.
There is a weird error that was introduced by the patch. Sometimes ale will now duplicate the last line at the end of the file, producing syntax errors etc.
There is a weird error that was introduced by the patch. Sometimes ale will now duplicate the last line at the end of the file, producing syntax errors etc.
Thanks very much for testing! I will fix that bug tomorrow.
@cbows I have fixed that bug with duplicate lines at the end now. It would be highly appreciated if you could test if #3974 works for you now.
@vimpostor did you ever manage to fix this issue? I am trying to debug slowness in ALE with fixers and came across this issue and this other issue you created in core vim too, but I didn't find an obvious culprit with VIM profiling. Although for me this is likely not the same issue since I don't use nvim.
@vimpostor did you ever manage to fix this issue?
Yes, I did find the solution in #3974, and you can apply the patch from that PR to fix the slowness. Unfortunately it has an unintended sideeffect of shifting the signcolumn briefly, which seems to be a bug in neovim.
Edit: I have fixed the flickering issues, could you please try out if #3974 (check out https://github.com/vimpostor/ale/tree/slow_fixer) works for you?
Sorry, I gave up on ALE after hours trying to figure out these performance issues. I moved on to COC and the performance is ridiculously better. My code actually gets formatted/fixed within a second now.
@hsanson Can you reopen #3974 please? Others may still be interested in the performance improvements.
Information
VIM version
NVIM v0.5.0-dev+1194-gc20ae3aad
Build type: RelWithDebInfo
Operating System: Ubuntu 18.04.5 LTS x86_64
What went wrong
I am working on a rather small Python file (~100 LOC) and
:AleFix
is very slow (~2s). Profiling shows, that most of the time is spent inale#util#SetBufferContents()
Specifically, the call to
setbufline
takes the longest:The biggest problem is that these two seconds are blocking, so I can't move the cursor.
Reproducing the bug
Install neovim 0.5 nightly, update ALE to the latest version and open a Python file with
black
andisort
fixers installed and enabled.:ALEInfo