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
Too much time cost in airline#highlighter#highlight() #1779
Comments
BTW: it might also be related to your airline theme and syntax highlighting. Check the output of |
I have read #1026 before, I tried. The result is adding I also tried From the profile log output, I think the issue reported here is different from that of #1026, the editor works fine at startup, but the performance degrades over time, possibly things continue to add up in the palette dict. I was expecting advice on this. |
The |
Indeed. I'l have another look |
Seems like now I have tweaked the configuration to a minimal that serves no notable real function other than just a slightly more fresh good looking, yet the lag is just untolerable. Disable it for now until vim-airline/vim-airline#1779 is fixed
I was hit by this as well and had to switch to some other statusline until this is fixed. |
Pleased provided more information as asked several times
… Am 10.10.2018 um 14:50 schrieb Johannes Wienke ***@***.***>:
I was hit by this as well and had to switch to some other statusline until this is fixed.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Here is my profile.log for that session: Things definitely get slower over time. |
Have you looked into the FAQ?
… Am 10.10.2018 um 15:40 schrieb Johannes Wienke ***@***.***>:
Here is my profile.log for that session:
https://gist.github.com/languitar/eecdacb3a81dd23fea6e37bc0e3b0b10
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Yes, I tried setting the caching, but then I frequently get broken renderings in airline. |
It would be good information to mention at the beginning. When does the caching not work?
… Am 10.10.2018 um 16:07 schrieb Johannes Wienke ***@***.***>:
Yes, I tried setting the caching, but then I frequently get broken renderings in airline.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.
|
In in active windows, some UTF-8 characters are rendered wrong. I'll try to provide a screenshot when I'm back at work. |
That sounds like a font issue rather than a caching issue. That only happens when caching is enabled?
… Am 11.10.2018 um 11:17 schrieb Johannes Wienke ***@***.***>:
In in active windows, some UTF-8 characters are rendered wrong. I'll try to provide a screenshot when I'm back at work.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Yes, otherwise that works well. |
I wonder why that happens. Might be a terminal problem. Have you tried a terminal or the gui?
… Am 11.10.2018 um 11:56 schrieb Johannes Wienke ***@***.***>:
left is without caching, right is with caching. See the artifcat at the bottom in the right version.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.
|
it's neovim in terminal. There's no gui verison I could test. |
What terminal? Please test with vim as well
… Am 11.10.2018 um 15:19 schrieb Johannes Wienke ***@***.***>:
it's neovim in terminal. There's no gui verison I could test.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.
|
termite v13. Same thing happens in stock vim. |
Btw, my configuration is online here: https://github.com/languitar/config-vim |
Several things to test:
thanks |
Which terminal does support termguicolors that I could test on this setup?
What kind of artifacts? The staircase symbol is actually what I configured. However, without caching, it doesn't stick out of the status line for inactive windows.
Without caching:
The important thing seems to be the base16-bright theme. Without that, the artifacts do not appear. If I use "base16-bright" the issue is also fixed. |
Ok, things are not entirely gone with the "base16-bright" theme, but at least things are better. |
Ah, your staircase separator confused me.
perhaps gnome-terminal or xfce-terminal? (just plain, without tmux or similar)
could that be a dup of #1807? |
Also happens in gnome-terminal.
As far as I can tell, not. The statusline deactivates properly, but the colors of some symbols are off in the deactivated statusline. Moreover, this simply doesn't happen without caching. |
So how do I reproduce this? |
Well, re-creating the highlighting groups is expensive. What kind of a system is this? I think this will get better, once the vim9 script branch is merged. But I need to re-do this |
2021, same issue persists. I cant use this plugin at all on my macbook air, its just not powerful enough... I have 37 plugins installed yet Airline seems to take 90% of my cpu time
|
Did you follow the wiki? BTW, it's an open source project, it lives from contributing. Complaining won't help to make it better. FWIW: since the various speed improvements I personally haven't seen this issue any more. Another possibility would be to test the vim9 branch, that is currently pending. I need some time to properly test and integrate it.
… Am 06.05.2021 um 21:25 schrieb Skylar ***@***.***>:
2021, same issue persists. I cant use this plugin at all on my macbook air, its just not powerful enough... I have 37 plugins installed yet Airline seems to take 90% of my cpu time
FUNCTIONS SORTED ON TOTAL TIME
count total (s) self (s) function
264 4.581206 0.069433 airline#check_mode()
16 4.494055 0.273587 airline#highlighter#highlight()
2184 3.909782 0.257406 <SNR>132_exec_separator()
6994 3.092190 1.310224 airline#highlighter#get_highlight()
4368 2.279014 0.138221 airline#themes#get_highlight()
191 1.991047 provider#python3#Call()
190 1.978191 UltiSnips#TrackChange()
27976 1.703343 <SNR>132_get_syn()
2626 1.684373 0.366774 airline#highlighter#exec()
264 0.531249 0.031849 airline#extensions#branch#get_head()
264 0.477169 0.016490 airline#extensions#branch#head()
126 0.387008 <SNR>122_parse_screen()
264 0.369182 0.048208 <SNR>134_update_branch()
264 0.290786 0.024917 <SNR>134_update_git_branch()
264 0.258194 0.012128 <SNR>134_config_fugitive_branch()
264 0.246067 0.011044 FugitiveHead()
264 0.225434 0.047352 fugitive#Head()
6 0.216495 0.171167 coc#float#create_cursor_float()
1134 0.208297 <SNR>132_GetHiCmd()
264 0.178082 0.121602 fugitive#Find()
FUNCTIONS SORTED ON SELF TIME
count total (s) self (s) function
191 1.991047 provider#python3#Call()
190 1.978191 UltiSnips#TrackChange()
27976 1.703343 <SNR>132_get_syn()
6994 3.092190 1.310224 airline#highlighter#get_highlight()
126 0.387008 <SNR>122_parse_screen()
2626 1.684373 0.366774 airline#highlighter#exec()
16 4.494055 0.273587 airline#highlighter#highlight()
2184 3.909782 0.257406 <SNR>132_exec_separator()
1134 0.208297 <SNR>132_GetHiCmd()
6 0.216495 0.171167 coc#float#create_cursor_float()
4368 2.279014 0.138221 airline#themes#get_highlight()
264 0.178082 0.121602 fugitive#Find()
2626 0.116937 <SNR>132_CheckDefined()
264 0.175864 0.088699 airline#extensions#hunks#get_hunks()
264 0.091497 0.084252 <SNR>134_update_untracked()
6994 0.078623 <SNR>132_get_array()
386 0.083163 0.078616 <SNR>95_notify()
264 4.581206 0.069433 airline#check_mode()
528 0.063893 airline#extensions#coc#get()
264 0.076821 0.062234 airline#extensions#whitespace#check()
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
BTW: This:
This definitely does not come from airline |
@chrisbra yes, I know, this profiling was informative in multiple ways and I also ended up disabled UltiSnips. FYI for anyone looking for an alternative, https://github.com/itchyny/lightline.vim seems to take nearly zero cpu time in comparison to this plugin. |
I understand this is an open source project. I posted because this issue was considered solved/closed, and I just wanted to say that from my perspective, on low end hardware, it's not. If I get a chance, I will look into maybe seeing if I can add a flag to disable some of the expensive parts of this plugins operations with the downside of losing some functionality while keeping the awesome themeing support and other features I love. |
well, as said, Using caching has very much speed up the performance for me and until very recently I haven't heard any complaints. I am a bit confused, why there are so many complaints now, because I cannot reproduce and I usually work on a slow virtual machine. |
BTW: This is a profile with vim and vim9 script and
Still some airline functions in there, but overall much better. |
@chrisbra I am using neovim
And mac os 11.4(beta) on m1 |
@skylarmb I guess it could be an issue in the external plugin for vim-airline, if the bottleneck in python3 call In my case, the issue is the highlighter functions. And, I found that it starts lags when I use neovim for a long time, and when I switch vim window from fern(file explorer) to file editing. The stack trace that I supplied was made when I was doing that switch. Sorry to forget to mention. |
Yes the highlighting functions are known to be slow. There is nothing I can do against it. I suggest to use the guide from the wiki.
… Am 10.05.2021 um 13:00 schrieb Sergey ***@***.***>:
@skylarmb I guess it could be an issue in the external plugin for vim-airline, if the bottleneck in python3 call
In my case, the issue is the highlighter functions.
And, I found that it starts lags when I use neovim for a long time, and when I switch vim window from fern(file explorer) to file editing. The stack trace that I supplied was made when I was doing that switch. Sorry to forget to mention.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
I think I may have found either the reason for this issue, or at least another source of slowdowns. I discovered this because I have been setting up Neovim's builtin LSP client which has this functionality for opening a "hover" window with the information for the symbol under the cursor (screenshot). I have been observing that my nvim setup would slow down over time, and today I got fed up with this and began investigating. Don't know why, but I thought that the floating windows were related to the issue, so I came up with a simple stress test which was a Python script which would repeatedly simulate presses of shift+K to trigger this hover window. The test was a success because it would consistently slow Vim down to a crawl after a few minutes of automatically pressing K. Anyway, after performing such a test, I ran the profiler and got a similar profile to the users above, i.e. most time is spent in the set rtp+=~/.config/nvim/plugged/vim-airline
let s:iteration = 0
let s:existing_winnr = v:null
function! StressTestTimerCallback(timer) abort
if s:existing_winnr && nvim_win_is_valid(s:existing_winnr)
call nvim_win_close(s:existing_winnr, v:true)
endif
" Triggered on the last iteration.
if empty(timer_info(a:timer))
return
endif
let hlgroups_rough_count = len(split(execute('highlight'), "\n"))
let text = printf('iteration:%d hlgroups:%d', s:iteration, hlgroups_rough_count)
let bufnr = nvim_create_buf(v:false, v:true)
call nvim_buf_set_option(bufnr, 'bufhidden', 'wipe')
call nvim_buf_set_lines(bufnr, 0, -1, v:true, [text])
call nvim_buf_set_option(bufnr, 'modifiable', v:false)
let winnr = nvim_open_win(bufnr, v:false, {
\ 'width': strdisplaywidth(text), 'height': 1,
\ 'relative': 'cursor', 'row': 1, 'col': 0,
\ 'style': 'minimal' })
let s:existing_winnr = winnr
let s:iteration += 1
endfunction
function! StressTestStart(total_iterations) abort
let s:iteration = 0
let s:existing_winnr = v:null
call timer_start(100, 'StressTestTimerCallback', {'repeat': a:total_iterations})
endfunction Needless to say, it requires Neovim, though it only seems to be effective on v0.5.0. To reproduce:
Anyway... the issue in my setup seems to be that Airline creates a ton of highlight groups in Oh, and also, P. S. Here's my profile after running the prototype stress test for 13 minutes: profile.log. |
so you are basically creating 200 random buffers? We could possibly clear the highlighting, if the old buffer no longer exists. But the highlighting group would still be there. That hints, that Vims datastructure is not optimized for too many highlighting groups (ping @brammool) Also, can you please show the output of |
it would also be interesting to see, how it runs on Vim9 Script |
Oh and that is not possible. |
So what we can see here is, |
Also, have you tried following the advice in the wiki? Basically about the caching and using a theme that does not switch colors? |
Yes, but only because that's a reliable way of forcing the performance issue, intended to help debugging. While working as usual hlgroups are still being leaked, but the slowdown becomes apparent much earlier than when Vim slows down to a crawl as with my stress test. EDIT: and 200 random windows.
No, but I believe that I found a bug in the default implementation. |
well, the highlighting groups are bound to buffers and you call something called
of Vim? possible As I said the current API does not allow to delete highlighting groups. That is nothing vim-airline can fix. We might have to dig into the vim source to fix that. |
nevertheless, I'll put it on my plate to dig this up in Vims source |
(of Airline) Pardon my ignorance, didn't remember. As a matter of fact I've worked around the slowdowns in my setup using noautocmd when opening floating windows, but I'll test hlgroup caching as well. |
By the way: just creating random buffers and opening them in a single window doesn't trigger the leak. |
Strange. Groups are still being leaked even with caching enabled. EDIT: ...though the slowdown is not as bad |
By the way, you don't even need some overcomplicated floating window setup, apparently, to reproduce the issue. Either I'm misunderstanding something, or Airline leaks groups even when just opening new buffers (with caching enabled, obviously). Try opening, like, five of them, then splitting the window and cycling through the buffers in both windows, and filtering groups with Gonna attempt reproducing on a minimal vimrc. |
Yes, I believe it is expected. It doesn't leak anything. It's just, once a buffer is displayed in a window it creates |
Try this:
But then... what is caching supposed to do? Oh, and I observe the same behavior with or without caching. |
Yes, as I said airline creates new highlighting groups, once a buffer is displayed in a non-active window, because one buffer could be modified the groups need to differ. Hm, perhaps we can link them to a default group since they are usually all the same. Also I am wondering why we have several caching prevents highlighting groups to be re-defined, even if they already exist. |
Regardless, the fact still stands that |
probably a mixture of both. A solution could be to use pre-defined groups, instead of creating a bunch of groups for each buffer for all different buffer states (and possibly we can save some of those, if we are not using powerline glyphs). But still the core vim functions are slow. |
Regardless, the fact still stands that `hlexists` and `synIDattr`
don't like having to loop through a lot of defined hlgroups. Do you
think this is a bug on the Vim side (i.e. the functions being slow) or
on the Airline side (creating identical hlgroups)?
The code assumes there aren't that many entries, thus it just does a
linear lookup in the table.
The lookup can be made much faster when using a dictionary (hash table).
However, then adding and removing groups becomes more expensive.
Probably the net effect is still positive, especially when there are a
lot of names. And when there are not many groups the overhead is most
likely unnoticeable.
…--
[clop clop]
GUARD #1: Halt! Who goes there?
ARTHUR: It is I, Arthur, son of Uther Pendragon, from the castle of
Camelot. King of the Britons, defeator of the Saxons, sovereign of
all England!
GUARD #1: Pull the other one!
The Quest for the Holy Grail (Monty Python)
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
environment
Vim
Vim airline version
CentOS 7
Linux titan 3.10.0-514.26.2.el7.x86_64
Airline configuration
actual behavior
I use vim with plugin vim-go. The editor seems to slow down gradually over time. I need to quit and reopen to start it over again.
:profile
result shows that a lot of time was spent iteratingg:airline#themes#{g:airline_theme}#palette[mode]
inside functionairline#highlighter#highlight()
Full profile.log attached. It was generated just by moving the cursor between different windows a few times.
The text was updated successfully, but these errors were encountered: