Performance and git color problems when switching windows

[adigitoleo]

Check list

• [x] I have read through the README (especially F.A.Q section)
• [x] I have searched through the existing issues

Environment info

• OS
  • [x] Linux
  • [ ] Mac OS X
  • [ ] Windows
  • [ ] Others:

Version info

NVIM v0.7.2
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by builduser

Features: +acl +iconv +tui

Question / Problem and steps to reproduce

This is probably several problems, but they are all related to buffer switching or opening new splits.

1. I observe significant (up to ~1s) performance impact when opening new splits from a buffer that is synced to a minimap (e.g. with :new, or even :help).
2. I observe significant performance impact when switching between windows that display buffers synced to minimaps using :wincmd.
3. When switching back to a buffer with a minimap that should show git diff colors, the colors are absent until a manual :edit (or opening a popup window in neovim, which must somehow reset things).

I tried disabling some of my more obvious plugins that could cause compatibility issues, like fugitive, ALE, or things that change highlights on events, but the issue seems to be with this plugin.

Screencapture below, without ALE or fugitive enabled.

minimap-nvim-slow.webm

[adigitoleo]

Based on a quick perusal of the code, I see the most obvious candidates for slow functions in update_highlight and get_window_info, both of which are called on WinEnter via source_win_enter. If I get time I may try to debug this further.

EDIT: After some more trials, this must be related to having g:minimap_git_colors enabled. I don't experience the slowdowns with it disabled.

[adigitoleo]

Aha, I believe the issues I'm observing depend on filetypes. The slowdown when switching windows is only really noticable when I'm switching to special buffers like an empty buffer from :new, maybe because they don't have a filetype or something they are causing problems. Perhaps these should be excluded by default.

In general, opening new windows for the first time still remains quite slow though.

[ZNielsen]

It appears that the video in your post is corrupt (at least that is the message github is giving me), so unfortunately I am unable to review it.

As for 1), I'm not entirely sure why :new would cause a delay, but opening a new file/buffer generally comes with a hit because we need to generate and cache the minimap, which involves scanning each line and recording the length. There is a ticket (#160) to push this scan to a background process and then update the minimap when it's done which which should help the issue, but making that work across platforms + the vim/nvim differences in managing background processes makes that a large feature that unfortunately may never get done.

I am curious about 2), since the caching should limit the performance hit of re-entering a buffer. Is that the issue that was dependent on filetypes?

I'm not able to repro 3). Is that with a command like bp/bn, or is that when navigating a split?

I think the video could be very helpful, if it's not too much trouble could you attempt to post it again? Thanks!

[adigitoleo]

I have updated the video which shows that swapping to a help buffer is faster than swapping to an empty buffer and the highlight issue. I was navigating splits with :wincmd, I suspect it is related to entering the window rather than entering the buffer. After playing around with a few other source trees I have seen that it isn't always easy to reproduce. Sometimes highlights work properly when leaving the help split. For me, the most reproducible delay and highlight corruption comes from navigating to splits with empty buffers, e.g. :new. Generally, I don't notice any delay unless the git diff for the file is fairly large (>500 lines).

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.