Rendering speed of suggestions is affected by length of current file

[klew]

With longer files (>50k lines) it starts to take longer and longer time to render reposes.

I attach short movie:

https://user-images.githubusercontent.com/205610/216761471-47fb6801-513d-4ee6-b457-09580eac552c.mp4

[pqn]

In #63 I eliminate an OffsetToPosition call: https://github.com/Exafunction/codeium.vim/commit/78382694eb15e1818ec6ff9ccd0389f63661b56f#diff-5127272f84a6dcfaad20fe14dc66437f542846b096fd7c41cdc9817a9ee23aacL145

However, locally testing, seems like the rendering is still slow. I'm not sure what work in the function is still O(N) though. I'm assuming you still experience the slowdown as well?

https://github.com/Exafunction/codeium.vim/blob/78382694eb15e1818ec6ff9ccd0389f63661b56f/autoload/codeium.vim#L132-L237

[klew]

I just tested it and now it take some time to load suggestions, but once response is ready, I can quickly switch between suggestions. So at least this part is fixed.

When Codeium is enabled on large file, I still see some slowness (short blocking) when I just type. It's probably related to remaining call which calculates cursor_offset - codeium#util#PositionToOffset('.', '.')

Maybe you could consider adding to language server API, ability to provide line numer + column, instead of absolute offset in whole string? This should remove dependency to this O(N) funciton completely.

[klew]

I just checked accepting suggestion, and it has the same long delay.

[pqn]

I've made some optimizations in https://github.com/Exafunction/codeium.vim/pull/69, curious to see how your case behaves now.

[klew]

It is at least few times faster. Thanks!

[pqn]

Great, I'll close this for now. One other place which is still O(N) is assembling the full document from the lines. Not sure if that's avoidable though -- in at least Neovim the buffer is stored as an array of lines according to this Reddit comment.