Background highlight job

[alerque]

The current Lua callback that runs on_change is pretty fast for small buffers, but it is still blocking and should be make async so that it won't ever hold up the UI on redraws. This probably means we need some sort of debouncing too so we never queue up more jobs than the currently running plus a most recent one.

[alerque]

My tests run pretty fast with only 1k+ files starting to hang, but #8 (comment) suggests this testing is pretty limited. There might be differences in how Lua is implemented by default in released vs. HEAD versions of Neovim, but I wouldn't expect that to be a regression.

[alerque]

P.S. If it's not performant we need to know right away, and maybe switch to the Python method ;-) I figured the built-in LuaJIT would be faster than Python, but if I'm wrong about that we should consider switching.

[fmoralesc]

The performance issues might be due to the additional pandoc rules not being well optimized, although I found that using the commonmark syntax on its own also was slow. We are also talking about 1k+ files (chapter from my thesis :p).

One advantage of the python method is that it does not execute in the same process as the lua code. But maybe that can be ameliorated once multiprocess features are incorporated in nvim (neovim/neovim#10843). That seems to have slowed down, though.

[alerque]

Arg. I actually thought these Lua callbacks would run in a different thread. This is dashing my hopes for my other use for this tech.

Is this where using RPC would do the trick? Or is the listener for that still going to block the foreground thread while it applies things? Does the Python route really allow stuffing highlight data into the buffer without blocking the UI display thread?

[fmoralesc]

Yeah, the RPC api does allow for asynchronous functions (the current python code is synchronous, though). Still at some point we have to go back to the main process (when we apply the highlights), but then we can use some extra logic to do less than rebuilding the whole highlighting after each document change.

[alerque]

Even if when we fix it to only update the minimum region to catch effects of a change event, I still don't like the idea of using the same process as the UI! The API docs suggest this should be possible but I've just coded it wrong in Lua, I'm looking into it.

[alerque]

Still at some point we have to go back to the main process (when we apply the highlights)

Figuring out the highlights is fast, it's applying them that is taking up our time anyway. Even if we only do that for a long buffer on first open, that's still a lot of blocking time that I am not comfortable with.

[fmoralesc]

I agree. I was just trying out the python version that works as a remote plugin an even that is slow in normal sized documents. When I made the notifications async, a different problem manifested: the highlighting lagged behind the cursor movements! I'm guessing nvim is pushing it to the back of some queue.

[alerque]

I wonder how Neomake / Syntastic / etc. handle this. I know they are running their jobs in the background, but are they able to update the buffer highlights to flag syntax errors async or are they actually blocking too? Maybe with relatively few things to update that isn't such problem and they aren't actually fully async either...

[fmoralesc]

syntastic at least is fully blocking: https://github.com/vim-syntastic/syntastic/blob/master/plugin/syntastic/highlighting.vim#L33-L60

Maybe part of the problem is that we are actually creating too many matches. As I said elsewhere, there is no real need to highlight all the types of elements. For example, there's no need to create matches for Text and Paragraph, since those are supposed to be "transparent". The issue might just be that we are passing around too much data too often.

[fmoralesc]

I was just testing some things and I think my hunch is correct: if we skip adding matches for Paragraphs and Texts, performance becomes reasonable again in my test documents (in one case we go from generating ~980 highlights to just 120). See #17