gen740 / SmoothCursor.nvim

MIT License
342 stars 13 forks source link

Strong performance impact (fancy enabled) #38

Closed Thanatermesis closed 10 months ago

Thanatermesis commented 1 year ago

I just noticed that in some cases, the performance impact is quite strongly affected, for example im editing a markdown file of 1400 lines (my todo list) with some folded blocks, so you can do the test with a similar file to easy reproduce it. Now do a :vs split (or even 2 of them) and keep pressed the key "j" or "k" for a few seconds, you will see how laggy neovim becomes, making the editor pretty unusable for this type of scrolling (not everybody does 30j or 30k, some just keep pressed the arrow key)

Seems like the issue is in CPU calculation so maybe the solution is to simply trigger the fancy effect ONLY when the cursor does a jump, like doing "30j" or similar, on completed actions 🤔 , this will save neovim to eat the cpu resources all the unnecessary times

Thanatermesis commented 1 year ago

Note also that my neovim is fullscreen and I use small fonts, I think this is an important thing to consider to reproduce this bug since there's lots of people which uses their terminals / editors only 10-lines-long 🤣 and should be very related to the calculation of lines, running this command I can see my terminal is around 80 lines long:

for i in $(seq 100) ; do echo $i ; done

gen740 commented 1 year ago

Thank you very much for using my plugin!

I am unable to reproduce the issue you are experiencing. Could you please provide me with more details regarding your platform and configuration and the minimum procedure required to reproduce the problem?

Additionally, as a way to minimize any potential performance impact, you could try setting the intervals value to a smaller value or reduce the length of the cursor body.

Thanatermesis commented 1 year ago

I already tried all the values and noticed the lag with any of them

Unfortunately I don't remember which file I was editing that did the lag, but I was able to reproduce it trying to remember what it contains (many words and folded sections), which is what I use for my TODO lists, lines containing tasks and sometimes folded to keep it better organized.

So, I was able to create similar files that reproduced the slowness, I noticed also that treesitter also makes it very slow 🤔 (I should report the performance impact to treesitter too?), so the first thing you may want to do and also in order to not interfere with this issue is: :lua vim.treesitter.stop()

Note that these files contains a vim modeline configuration in the end, to set the file to markdown and folded. So this is a file on which you can see the lagged issue on the cursor:

http://sprunge.us/CrXsLw , in case that you have a powerful cpu and you don't see the lag try with this version of the file instead: http://sprunge.us/ngJiug , the last one is extremely slow on my computer and I almost cannot use neovim with it (vim works without slowness)

By turning off the treesitter and runnning :SmoothCursorToggle you can play with the k and j keys, but when you toggle again SmoothCursor you can notice the lag while scrolling lines

gen740 commented 1 year ago

Sorry for my late reply.

By turning off the treesitter and running :SmoothCursorToggle you can play with the k and j keys, but when you toggle again SmoothCursor you can notice the lag while scrolling lines

To be honest, I can't notice the lag. (As you mentioned, enabling treesitter causes a lot of lag.) I could not find the performance impact caused by smoothcursor.

Here is a Tip. Treesitter can disable by the size of the buffer (or other flags). Disabling treesitter on a large markdown file would solve this problem.

require('nvim-treesitter.configs').setup {
  highlight = {
    enable = true,
    disable = function(lang, bufnr)
      local byte_size = vim.fn.getfsize(vim.api.nvim_buf_get_name(bufnr))
      if byte_size > 512 * 1000 then
        return true
      end
      return false
    end,
  },
}

Performance impact on the markdown file seems to be a treesitter-issue.