Bad Performance

[orhnk]

Files contain >4000 loc (when satellite is enabled) have big impact on performance

https://github.com/lewis6991/satellite.nvim/assets/101834410/39e96810-eba0-4ee7-b3b8-9d22455384e8

45

[lewis6991]

Sorry, not enough information.

[orhnk]

I didn't mention this because it was a bug in my config/system etc. The plugin just needs to improve performance overall!

Just try it on a "big" file and you'll reproduce.

[justinmk]

Just try it on a "big" file and you'll reproduce.

Can reproduce on a 10K lines markdown file.

[lewis6991]

Test case?

[justinmk]

Most noticeable for me on https://github.com/justinmk/notes/blob/master/delicious.md but haven't narrowed down minimal steps. :syntax off and vim.treesitter.stop() don't fix it, only :SatelliteDisable

[lewis6991]

I can barely open that file with a minimal config. It completely locks up with set breakindent, and even after disabling that it is still really slow with all my plugins disabled (including Satellite).

We can explore adding some optimizations in places so massively long lines can be handled better, but whatever we do the functionality provided by this plugin is never going to be free.

[justinmk]

Graceful degradation would be totally acceptable and avoids needing to manually :SatelliteDisable.

[lewis6991]

Hmm, I can't replicate with:

vim.opt.rtp:prepend '/Users/lewrus01/projects/satellite.nvim'
require('satellite').setup()

vim --clean -u min.lua delicious.md

[justinmk]

Ok I'll try to narrow it down

[orhnk]

could you remove the invalid flag from the issue and reopen it?

[lewis6991]

We've not determined anything yet. The initial description contained no useful information other than "bad performance".

Tbh, I'm not really sure why Justin commented here as it seems his issues are with very specific non-normal files.

[justinmk]

I commented here because :SatelliteDisable ameliorates the issue.

[justinmk]

Actually treesitter is the issue, not satellite.

[dstein64]

It looks like for each mark, nvim_win_text_height is called with start_row set to 1 and end_row set to the line of the mark.

If that's the case, I think that could cause a slowdown for large files with many marks, since nvim_win_text_height has to loop from start_row=1 to end_row.

If my interpretation is correct (that successive calls are being made to nvim_win_text_height for the marks, with each call having start_row set to 1), one possible idea to reduce the slowdown could be to incorporate each call to nvim_win_text_height into the next, for each refreshing cycle, a dynamic programming approach.

For example, suppose that for a refreshing cycle that there is a call to nvim_win_text_height with start_row=1 and end_row=20 for mark 1, followed by a call to nvim_win_text_height with start_row=1 and end_row=40 for mark 2. Perhaps the second call could be adapted to use start_row=21 and add to that what has already been calculated earlier for mark 1. Then a subsequent call with e.g., end_row=80 for mark 3, could use the result that had just been calculated for end_row=40 for mark 2 (which itself used the earlier result for mark 1), added to what's calculated for start_row=41 (instead of start_row=1). I guess some additional handling would be necessary to account for or prevent successive calls from spanning the same closed fold.