You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using diffview to review my commits. My workflow is to stage individual files in diffview. Staging each file will causes diffview to update its display, which is the right way. However I feel that after doing that for a while, the performance degrades. Staging a single file can take in the range of one second.
I have multiple neovim plugins which make git calls, too. For instance nvim-tree, which at these times throws me warnings saying that it's disabling its git integration because 5 git calls took more than 400ms.
Because the initial performance is good, I now think that the issue is caused by git lock contention. I see that most other neovim plugins using git make use of the --no-optional-locks flag to reduce contention, but diffview doesn't.
My theory is that adding --no-optional-locks in places where it would make sense within diffview should help with the performance issues I've been seeing.
Expected behavior
No response
Actual behavior
Getting poor performance after long diffview use and staging/diffing many files.
Steps to reproduce
I can't really reproduce this on-demand. However one thing I'm trying recently is to force diffview to use no-optional-locks on all its calls. The way I achieved that is by patching my lua/diffview/job.lua:
local function prepare_env(env)
- local ret = {}+ local ret = {"GIT_OPTIONAL_LOCKS=0"}
for k, v in pairs(env) do
table.insert(ret, k .. "=" .. v)
end
I've been running diffview with this change for a while and noticed no issues, and I didn't get serious slowdowns since then (but then again I wasn't getting them that often, so it's not definitive proof that it helps yet).
Health check
Output of :checkhealth diffview
==============================================================================
diffview: require("diffview.health").check()
Checking plugin dependencies ~
- OK nvim-web-devicons installed.
Checking VCS tools ~
- The plugin requires at least one of the supported VCS tools to be valid.
- OK Git found.
- OK Git is up-to-date. (2.47.0)
- OK Mercurial found.
- OK Mercurial is up-to-date. (6.7.4)
Log info
Relevant info from :DiffviewLog
############################
### PUT LOG CONTENT HERE ###
############################
Description
I'm using diffview to review my commits. My workflow is to stage individual files in diffview. Staging each file will causes diffview to update its display, which is the right way. However I feel that after doing that for a while, the performance degrades. Staging a single file can take in the range of one second.
I have multiple neovim plugins which make git calls, too. For instance nvim-tree, which at these times throws me warnings saying that it's disabling its git integration because 5 git calls took more than 400ms.
Because the initial performance is good, I now think that the issue is caused by git lock contention. I see that most other neovim plugins using git make use of the
--no-optional-locks
flag to reduce contention, but diffview doesn't.My theory is that adding
--no-optional-locks
in places where it would make sense within diffview should help with the performance issues I've been seeing.Expected behavior
No response
Actual behavior
Getting poor performance after long diffview use and staging/diffing many files.
Steps to reproduce
I can't really reproduce this on-demand. However one thing I'm trying recently is to force diffview to use no-optional-locks on all its calls. The way I achieved that is by patching my lua/diffview/job.lua:
I've been running diffview with this change for a while and noticed no issues, and I didn't get serious slowdowns since then (but then again I wasn't getting them that often, so it's not definitive proof that it helps yet).
Health check
Output of
:checkhealth diffview
Log info
Relevant info from
:DiffviewLog
Neovim version
Operating system and version
Linux 6.10.12-200.fc40.x86_64 x86_64 GNU/Linux
Minimal config
No response
The text was updated successfully, but these errors were encountered: