You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Introducing a syntax error early in a large file will cause many language servers and linters to spew out potentially hundreds of errors that are difficult for any editor to deal with. The problem is visible when profiling ALE.
" We don't need to add items or sort the list when this list is empty.if!empty(l:linter_loclist)
" Add the new items.callextend(l:info.loclist, l:linter_loclist)
" Sort the loclist again." We need a sorted list so we can run a binary search against it" for efficient lookup of the messages in the cursor handler.callsort(l:info.loclist, 'ale#util#LocItemCompare')
endif
Solution
There's no one solution. Instead, there are many solutions, and we should do all of them at once to greatly improve ALE's efficiency.
Where possible, mark which linters will report sorted output anyway, so we can avoid calling sort for problems from those linters.
Avoid sorting the same list multiple times if possible.
Avoid sorting when only one linter is reporting issues at a time.
Introduce g: and b: scoped ALE setting with a low number that simply ignores all but N many problems from any source by default. (No point reporting 100 errors at a time, etc.)
Introduce special code for particular tools like flake8 that simply report the first syntax error and throw all other errors away, as special cases.
Consider using an alternative sort algorithm, which could mean breaking the rule of "only Vim script" in this one circumstance, with a Vim script fallback. Perhaps Lua or Python sorting is a lot faster. (We would add an ale#util#Sort internal API function.)
The text was updated successfully, but these errors were encountered:
Any further updates on this? Working on large files is practically impossible, I have to turn off the LSPs. This is how it looks on head ATM, no screen-keys, but I'm moving at all times, which you can't see because my vim just freezes because of the errors.
Edit;
I'd say, turning off inline error messages improves performance by like 20%. Not sure if there are other configurations I can use to speed things up? Like for example, I see absolutely 0 need for the constant :messages updates on the item below cursor.
This issue with errors in larger files isn't exclusive to Ale, I switched from COC to Ale, because CoC was also breaking in this file, it's 2k lines, and if you have an object, with a single structural error, it generates an error for literally each, valid (now invalid because of the outer structural error) item within said object.
Perhaps an option to limit errors within an object and show the outermost error only, at first. Not sure how these types of things work, but happy to help.
Problem
Introducing a syntax error early in a large file will cause many language servers and linters to spew out potentially hundreds of errors that are difficult for any editor to deal with. The problem is visible when profiling ALE.
Which points to this code in
engine.vim
.Solution
There's no one solution. Instead, there are many solutions, and we should do all of them at once to greatly improve ALE's efficiency.
sort
for problems from those linters.g:
andb:
scoped ALE setting with a low number that simply ignores all but N many problems from any source by default. (No point reporting 100 errors at a time, etc.)flake8
that simply report the first syntax error and throw all other errors away, as special cases.sort
algorithm, which could mean breaking the rule of "only Vim script" in this one circumstance, with a Vim script fallback. Perhaps Lua or Python sorting is a lot faster. (We would add anale#util#Sort
internal API function.)The text was updated successfully, but these errors were encountered: