Poor performance when scrolling

FalcoGer commented 1 year ago

Description

When scrolling through this python file, it becomes very choppy and the framerate becomes quite bad.

When the tagtree is opened, it becomes a lot worse. Curiously it is only with these specific plugins (see config below).

Some more observations:

With just bufferline disabled, it is smooth, even with the tag tree open.
With airline disabled, is it smooth normally, but with tag tree open it is super choppy.
With tagtree disabled, no chop happens either.
With line numbers disabled it is smooth except when it is about to update the context, then it drops a few frames
The problem completely disappears if I turn context off with :TSContextToggle
I run nvim on my potato laptop with an AMD A12-9720P RADEON R7
Neovim version

NVIM v0.10.0-dev-5ceb2238d

Expected behavior

Smooth scrolling

Actual behavior

Choppy scrolling with low fps Even much worse when the tagtree is opened.

Minimal config

runtime! debian.vim
set nocompatible

call plug#begin(expand('~/.vim/plugged'))
Plug 'vim-airline/vim-airline'
Plug 'preservim/tagbar'
Plug 'akinsho/bufferline.nvim', { 'tag': '*' }
Plug 'nvim-treesitter/nvim-treesitter', {'do': ':TSUpdate'}
Plug 'nvim-treesitter/nvim-treesitter-context'
call plug#end()

set mousemoveevent
lua << EOF
    require("nvim-treesitter.configs").setup({})
    require("treesitter-context").setup({enable = true, line_numbers=true})
    require("bufferline").setup({})
EOF

set noshowmode
nmap <silent><C-t> :TagbarToggle<CR>

set number
set relativenumber
augroup numbertoggle
    autocmd!
    autocmd BufEnter,FocusGained,InsertLeave * if(getbufinfo('%')[0]['listed'] == 1 || &buftype == 'help') | set relativenumber | endif
    autocmd BufLeave,FocusLost,InsertEnter   * set norelativenumber
augroup END

Steps to reproduce

wget -O /tmp/test.py https://raw.githubusercontent.com/FalcoGer/proxy/877891532bde972f980db0b28aae5d5a24273158/application.py
nvim -u minimal.vim /tmp/test.py (can't do --clean because it doesn't know what Plug is?)
:TSInstall python
gg
Press and hold down

Open tagbar with and scroll back up to see even worse performance.

lewis6991 commented 1 year ago

Are you sure this is an issue with this plugin?

FalcoGer commented 1 year ago

Are you sure this is an issue with this plugin?

It started to behave poorly after installing this plugin. I don't know what the issue is. I just want to use nvim, I don't know how to profile it or how to find the bottleneck. I write python, c# and c++ programs, not vim plugins. All I know is that it becomes better if I change any of those settings (and it took me all morning just to come up with the minimum config). The problem also completely disappears if I turn the context off (:TSContextToggle).

So where do you propose I post the bug report to? Everybody is just going to blame each other because of the nature of this bug.

What I find most curious in this lineup is bufferline, because as far as I know it doesn't do anything on CursorMoved or WinScrolled. Maybe the issue is partly because the context is pushed down by one line?

lewis6991 commented 1 year ago

Issues can't be fixed if they can be properly diagnosed. Just saying this plugin is slow for you isn't a lot to go by, and doesn't provide much motivation for maintainers to fix it.

The problem also completely disappears if I turn the context off (:TSContextToggle).

But also when you disable any one of three other plugins? This could mean anything.

I just want to use nvim, I don't know how to profile it or how to find the bottleneck. I write python, c# and c++ programs, not vim plugins.

Treesitter is still considered quite experimental. If you just want to use nvim, then I suggest you avoid using experimental features and plugins, especially if you're not in a position to debug issues.

So where do you propose I post the bug report to? Everybody is just going to blame each other because of the nature of this bug.

If no useful bug report can be created, then nowhere. Not one vim plugin author gets paid for developing vim plugins, it's something they do for free in their spare time. No one wants to debug an issue for it to turn out to not be an issue with the software they are maintaining, it is a massive waste of their time. Plugin authors just want to use nvim too.

What I find most curious in this lineup is bufferline, because as far as I know it doesn't do anything on CursorMoved or WinScrolled. Maybe the issue is partly because the context is pushed down by one line?

Hmm, I kind of doubt it but maybe. Either way, requiring 4 plugins to reproduce an issue definitely feels like a time sink to debug, especially when 2 of the plugins aren't really used in the nvim community anymore.

I'll try and repro the issue with the steps you've provided, but I won't spend hours trying to debug this.

FalcoGer commented 1 year ago

especially when 2 of the plugins aren't really used in the nvim community anymore.

Which two, and what are the alternatives? I didn't find any deprecation warnings and from what I can see all of them have had their repos updated relatively recently, from two days ago to just 2 months ago. That seems pretty recent to me.

requiring 4 plugins

Well if you take out vim-airline it still gives poor performance if tagbar is open. I think it's vim-airline's tagbar integration that is causing that particular dependency for the bug. So it's tagbar and bufferline, which makes 2, not 4.

What's also interesting to me is that it only stutters when it updates when line numbers are off. So it probably isn't the finding out if it needs updating, but the updating itself or the creation of the float itself.

If no useful bug report can be created, then nowhere.

Is this a bug or is it not? What makes a report useful? I provided everything needed to reproduce the issue, or at least I tried to. Just because it might not be a single project's fault but an interoperability issue still makes this a problem that should be resolved, or not? It seems unreasonable to suggest that it shouldn't be reported because there is no place to do so. What am I to do instead? Right now my choices are to live with the lag or to not use this combination of settings and plugins. Neither seems very appealing. If you have a solution, I would be happy to try it.

A workaround that works for context.vim enables you to not use autocommands for CursorMoved and WinScrolled but just on CursorHalted, which would be sufficient for me and probably is implementable with reasonable effort.

I'll try and repro the issue with the steps you've provided, but I won't spend hours trying to debug this.

Thank you.

lewis6991 commented 1 year ago

Is this a bug or is it not?

Well that has not been confirmed yet. A repro that only requires this plugin would confirm it as a bug. Identifying the root cause of issues is the hardest part, which authors hate doing. Fixing them is often easy.

It seems unreasonable to suggest that it shouldn't be reported because there is no place to do so. What am I to do instead?

Again, no one gets paid to fix these issues and you are not owed anything. You should take this software as is and just be grateful it even exists. You are free to raise issues, but you should never assume or expect they get fixed by someone that isn't you.

Right now my choices are to live with the lag or to not use this combination of settings and plugins. Neither seems very appealing. If you have a solution, I would be happy to try it.

When using open source software in a niche community, fixing the problem yourself should always be an option. Otherwise, yes, accepting the lag or not using this plugin are very valid options.

A workaround that works for context.vim enables you to not use autocommands for CursorMoved and WinScrolled but just on CursorHalted, which would be sufficient for me and probably is implementable with reasonable effort.

The updates are already debounced, so I don't think this will make much difference. We could always increase the debounce duration.

GiuseppeMP commented 10 months ago

Hey guys, how are you doing?

@lewis6991 Ty by the replies!

It's seems to be a sort of issue/conflict with preservim/tagbar.

You need to open tagbar in order to reproduce the issue.

https://github.com/nvim-treesitter/nvim-treesitter-context/assets/4944009/34490047-7467-4db4-88b1-773ec4de61c9

litoj commented 10 months ago

This is probably mostly off topic aside of performance concerns, but could using the nvim 0.10 virtual lines (like dropbar.nvim) improve the performance in any way? I tried it on a 400 line markdown file (giant lists for easy folding, depth ~4) and it was certainly a noticeable drop in scrolling, though it was quite slow beforehand too.

file in question

lewis6991 commented 10 months ago

No

nvim-treesitter / nvim-treesitter-context