Performance improvement about chromatica.nvim HOT 6 CLOSED

reduce the number of RPC calls

Note that add_highlight() does not make a "RPC call" call per highlight, it makes a RPC notifictation per highlight, which doesn't necessitate context switching and thus can be done efficiently in a loop.

I think the problem is rather than nvim currently makes too many redraws when one calls add_highlight() from a async context. I will look into this. In the meanwhile, something to try could be, make Chromatica._highilght callable as @neovim.function("_chromatica_apply_highlights", sync=True) and replace self._highlight(filename) with self.vim.funcs._chromatica_apply_highlights(filename, async=True). If all updates (clearing and adding) is done from the same sync python function, then the user won't see any intermediate state (no blinking) either.

avoid re-highlighting of existing codes

clear_highlight() doesn't require to clear the entire buffer, it is possible to pass a line range to clear. Also add_highlight() will adjust highlights to inserted/deleted lines, unlike matchaddpos() which go out of sync below the inserted line.

from chromatica.nvim.

@bfredl Thanks for the inputs. I will them. I was thinking return all highlight groups in one or few RPC calls could reduce the overhead of using RPC itself (since add_highlight() will need n RPC calls where n is the number of symbols in the current buffer or "view"). It needs a more detailed analysis on the performance of add_highlight(), matchaddpos() and other parts that are involved. I wasn't following the development of neovim closely, so maybe someone has already done such an analysis. I will try to find and work on it.

BTW, the reason why I am using clear_highlight() is the highlight is not correctly "following" the text.

from chromatica.nvim.

There would be possible to cluster many highlight calls to one rpc call using neovim/neovim#4568. Performance-wise it should be more-or-less equivalent to the workaround above, as rpc performance is already not so bad (it would reduce from 1 to 0 roundtrips, not from n down to 1 or 0) the main effect would still be to avoid unnecessary redraws (and allow "atomic" updates without blinking), the benefit would instead be from a usability perspective as we could implement buffer.update_highlights(src, lines, highlights) which will update many highlights at once in the correct way.

BTW, the reason why I am using clear_highlight() is the highlight is not correctly "following" the text.

If you mean column adjustment, yes that something that's almost entirely lacking from vim. neovim/neovim#5031 is investigating to improve that ( for add_highlight(), matchaddpos() cannot be improved as it associates highlights with the window and not the buffer).

from chromatica.nvim.

Cool. Thanks for pointing that out.

from chromatica.nvim.

I have tried the "nvim_call_atomic" which introduced in neovim/neovim#4568. There is almost no difference in the performance (in terms of time). But the "blinking" problem improved.

Also tried matchaddpos() and matchaddpos() with nvim_call_atomic. The performance is worse in these two implementations (comparing to original implementation).

Need more investigation on them. The nvim_buf_add_highlight function is a lot slower than I expected. Not sure if I can do any improvement from the plugin-side.

from chromatica.nvim.

I think there is nothing more to squeeze from neovim/RPC side. It's mainly just libclang now.

from chromatica.nvim.