Bug 579284 - commit message component lags (again)
Summary: commit message component lags (again)
Status: RESOLVED FIXED
Alias: None
Product: EGit
Classification: Technology
Component: UI (show other bugs)
Version: 6.1   Edit
Hardware: PC Windows 10
: P3 normal (vote)
Target Milestone: 6.2   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-03-16 13:10 EDT by David Frenzel CLA
Modified: 2022-03-17 08:37 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Frenzel CLA 2022-03-16 13:10:26 EDT
I realize that https://bugs.eclipse.org/bugs/show_bug.cgi?id=565019 was reported 2 years ago so I assumed that opening a new issue is the way to go. 
However with 5.13 but also 6.1 I am still seeing the same behavior. 

It only happens when a repository is selected. After a fresh start of Eclipse the typing works without lag. As soon as I select any checked out project in the Project Explorer (for example) the typing starts lagging again. Copy & Paste works fine. Deleting characters (backspace) also lags. If needed I can provide a video of how that looks like.

What's weird is that if that problem existed for everyone it would be noted somewhere here. It's hard to believe that people develop with this day to day without going insane :)

Cheers - David
Comment 1 Thomas Wolf CLA 2022-03-16 16:37:29 EDT
I know that this problem still exists. Personally, I haven't seen it in a long time, and it occurred for me only rarely. But it _is_ there.

I have never been able to trigger it knowingly, so I had no chance to debug it.

From code inspection, I do suspect it's linked to bug 578768. Might even be a duplicate.

There's a DocumentListener on the text viewer, which after some further indirection ends up invoking StagingView.updateCommitButtons() on every change to the commit message text. StagingView.updateCommitButtons() is slow, and also does much more work than what what would be minimally needed in this particular case.
Comment 2 David Frenzel CLA 2022-03-16 19:16:30 EDT
I think I have actually found the root cause and I'll leave that here for you to consider: For some reason, my .gitconfig (global) is located on a network drive that my company attaches to our computers where it stores some user files. Going through the code you mentioned got me thinking whether it is reading the git configuration somewhere in the updateCommitButtons() cycle.
I had to do some changes on my machine and that assumptions appears to be true. I changed the location of the global git configuration and suddenly the symptoms disappear. Whenever I change it back the lagging returns.

This would point into the direction of caching information as it is not plausible that the git configuration will change on every key stroke.

Looking forward to improvemnts - thanks in advance for the great work. My Java knowledge was barely enough to dig a bit into the source code. 
Feel free to keep this open as a reference or close it as duplicate.
Comment 3 Thomas Wolf CLA 2022-03-16 19:45:45 EDT
Yes, part of the problem is repeated accesses to the git config on disk, which is especially expensive on Windows if a git config is not on the local disk. But caching the git config alone is not sufficient. EGit also should do the update only if the toggle state of the "Add Change-ID" button did actually change.
Comment 4 Eclipse Genie CLA 2022-03-17 03:39:33 EDT
New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/191983
Comment 5 Thomas Wolf CLA 2022-03-17 04:06:50 EDT
(In reply to Eclipse Genie from comment #4)
> New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/191983

@David: can you give this a try, please? You could download https://ci.eclipse.org/egit/job/egit.gerrit/2585/artifact/org.eclipse.egit.repository/target/repository/ as a ZIP file and install EGit/JGit from that.
Comment 6 David Frenzel CLA 2022-03-17 04:50:15 EDT
Wow, that was quick. I just downloaded and installed the package and the lag is gone entirely. I tried it with different repository sizes and different staged/unstaged changes - no degradation in performance at all.

Can I provide you with more specifics or is that feedback sufficient?
Comment 7 Thomas Wolf CLA 2022-03-17 05:33:09 EDT
(In reply to David Frenzel from comment #6)
> Can I provide you with more specifics or is that feedback sufficient?

That's sufficient, thank you! If you had a case where the lag was reproducible (git config on remote disk) and the lag is now gone in that setup, then it's fine.

We both arrived at the same conclusion from source analysis, the change was done to mitigate the problems identified in that analysis, and if the problem is gone now, I would say the analysis was spot-on and I'd be happy to merge this even though I personally wasn't able to reproduce the problem.

If the change should cause new bugs: we're very early in the 6.2 release cycle; there's ample time to surface and resolve any potential problems this change might introduce. (I don't think it does; but one never knows... There are some users who work with EGit nightly regularly.)