Bug 578768 - slow org.eclipse.egit.ui.internal.staging.StagingView.updateCommitButtons ()
Summary: slow org.eclipse.egit.ui.internal.staging.StagingView.updateCommitButtons ()
Status: RESOLVED FIXED
Alias: None
Product: EGit
Classification: Technology
Component: UI (show other bugs)
Version: 6.0   Edit
Hardware: All All
: P3 minor (vote)
Target Milestone: 6.7   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-02-15 11:09 EST by Jörg Kubitz CLA
Modified: 2023-09-05 04:11 EDT (History)
3 users (show)

See Also:

Attachments
StagingView sampling.png (115.65 KB, image/png)
2022-02-15 11:09 EST, Jörg Kubitz CLA 		no flags Details
Git Repository State profiling.png (152.08 KB, image/png)
2022-02-15 11:10 EST, Jörg Kubitz CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jörg Kubitz CLA 2022-02-15 11:09:41 EST 
Created attachment 288054 [details]
StagingView sampling.png

We have a large workspace with a large git repository. After saving a file the UI freezes for several seconds - only when the Stagingview is open.
We took stacktraces which point to 
org.eclipse.egit.ui.internal.staging.StagingView.updateCommitButtons ()
runninng in the UI thread.
We understand that the org.eclipse.jgit.lib.Repository.getRepositoryState () may take a while to inspect the git repository. 
could it please run in the background and then post the state to the git Staging View after the calculation done?
Comment 1 Jörg Kubitz CLA 2022-02-15 11:10:10 EST 
Created attachment 288055 [details]
Git Repository State profiling.png
Comment 2 Jörg Kubitz CLA 2022-02-15 11:12:02 EST 
A colleague had the idea, that the commit button should be disabled insync and only enabled after async state calculation to avoid a false isEnabled state.
Comment 3 Thomas Wolf CLA 2022-02-15 14:50:14 EST 
Yes, there's way too much going on there. It also queries the state multiple times, and also resolves HEAD, and whatnot. This needs a clean-up to query needed info only once, and if possible cache data it needs between calls. The problem is when to invalidate this cached data and re-query it.
Comment 4 Jörg Kubitz CLA 2022-03-03 03:19:51 EST 
(In reply to Thomas Wolf from comment #3)
> The problem is when to invalidate this cached data and re-query it.


@Thomas, do you plan any improvements on this for next version? Otherwise i would into it.
Comment 5 Thomas Wolf CLA 2022-03-03 03:23:05 EST 
I've planned some clean-up in this area in 6.2. Not sure it can be fully resolved, but it should be possible to do better than currently.
Comment 6 Jörg Kubitz CLA 2022-03-03 03:50:10 EST 
(In reply to Thomas Wolf from comment #5)
> I've planned some clean-up in this area in 6.2. Not sure it can be fully
> resolved, but it should be possible to do better than currently.

ok, great, thanks.
Comment 7 Jörg Kubitz CLA 2022-07-25 08:32:55 EDT 
ping @Thomas
was there any activity in this area?
Comment 8 Jörg Kubitz CLA 2023-08-17 03:00:05 EDT 
I added a commit for improvement: https://git.eclipse.org/r/c/egit/egit/+/203698
Comment 9 Matthias Sohn CLA 2023-09-04 07:12:11 EDT 
(In reply to Jörg Kubitz from comment #8)
> I added a commit for improvement:
> https://git.eclipse.org/r/c/egit/egit/+/203698

this change was merged as c22a3c0acfbd6179b6b6a95e19016564f67edf19