Performance issues

[folke]

hi!

First of all thank you again for another amazing plugin!

I did some preliminary testing and this plugin does seem slower than something like ibl.
Especially noticeable when scrolling. (I am also using mini.animate, so that may exaggerate the issue)

Maybe some caching on changedtick or a debounce may be needed?

I also noticed that indents are only displayed for the current window. This is intentional I guess?

[glepnir]

I also noticed that indents are only displayed for the current window. This is intentional I guess?

yup

I did some preliminary testing and this plugin does seem slower than something like ibl.

I guess the rendering logic is executed on every time win_line invoke . maybe can add some conditions to avoid. I'm a little curious about the performance difference. It may also be spent searching for indent of blank lines ？

[LokiNaBoki]

Hi, I love the plugin. I have not noticed any performance issues compared to ibl. However I took a look at the code and I think there are some things that could be done to make it faster.

1. The checks on expandtab and opt.exclude could be moved from on_line to on_win, so they are checked once per window instead of for each line. Just like the check if it is the current buffer or not is already done.
2. current_line_range is calculated for every line, even though it will always have the same return values (for one redraw) - it could also be moved to on_win and stored somewhere.
3. This one I'm not sure if will improve performance, but the docs say that nvim_buf_get_lines() should be preferred over nvim_buf_get_text() when retrieving entire lines and in the plugin a part of the line is retrieved only in non_or_space. Maybe it would also be a good idea to pass the line to the non_or_space and use string.sub to check specific char.
4. Even less sure about this one, but I think that calling vim.fn.shiftwidth() or vim.fn.winsaveview() every time takes non-negligible time and could be called once and stored somewhere (just like current_line_range in 2.)

I can try to make a PR, but wanted to see what you think before I do that.

[glepnir]

ofc .

[glepnir]

thanks @LokiNaBoki for your advice, @folke did you still get performance issue ? i tried with some tens of thousands of lines C/C++ files mini still fast.