Community
Participate
Working Groups
Have an eclipse with no builders or jobs running. Make sure CPU is idle. Type a commit message quickly (i.e. hammer on your keyboard with all fingers). The commit message text does not update in real time, but has a notable delay. It looks like after every key stroke some heavy calculation is done. Maybe you remember the create branch dialog and it's branch name validation 2 years ago, which was also slow on repositories with many branches like eclipse.platform. This feels very similar. I may be able to attach a profiler in the near future when there is some spare time. Side note: I also remember the icon next to the author label flashing on each key stroke in one of my installations. That might be related (i.e. some re-layout of the complete component with each key stroke would surely consume some CPU).
It's caused by https://git.eclipse.org/r/c/egit/egit/+/162746/9/org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/staging/StagingView.java#113, line 1422. Instead of setting the commit button enablement only, a complete relayout is triggered.
The commit buttons are not updated on keystrokes AFAIK. Also: cannot reproduce on Mac. Do you have a warning message above the commit message text viewer? It _does_ seem a bit slower when there are warnings. Probably that warning label should update only if something really changes (text or icon), and StagingView.updateMessage() should force a redraw only if the label did indeed change (or was hidden/shown). The commit buttons may update when there are errors on staged resources and "block commit on errors" is enabled, but that also shouldn't happen on every keystroke?
I have no debugger available right now, but in my last debugging session the problem was StagingView, line 1466, "commitAndPushButton.requestLayout();" and I'm certain it was triggered on each key stroke. That line was introduced with the changes for "Push HEAD" and did not exist before, therefore it's also reasonable I did not experience that in earlier egit versions.
From code inspection, it appears that this would come from CommitMessageComponent.addListeners(), which adds various modify listeners that all call ICommitMessagecomponentNotifications.updateStatus(). The implementation of that in StagingView calls updateMessage(), which produces way too many redraws. It redraws even if no message text changed. Moreover, it re-evaluates hasWarningsOrErrors() every time. Looks like this whole area would need some refactoring.
New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/169963
Gerrit change https://git.eclipse.org/r/c/egit/egit/+/169963 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=bbeed925b61f786285556c7448db26e9d046818c
Closing. If the problem still occurs with EGit nightly feel free to re-open.
I am getting the same behavior with version 5.11 and have been getting it for a while now Not sure if it is the cause is exactly as described here, but the result surely is. When Eclipse is freshly started, there are no delays at all. After a while which can be quite long, but also pretty quick (few hours), then it can quite slow, sometimes taking a few seconds per character to show up. Only solution is to restart Eclipse. Almost feel that over time, maybe as different editor or compare windows are opened, that some listeners are added and never removed. Please advise if there are any steps to gather information when it happens again.
Eclipse 2023-09 same issue: very slow typing echo in commit message field after several hours IDE uptime. Proper behaviour resumes next to restart of Eclipse.
