Community
Participate
Working Groups
Bug 535516 demonstrated that the GIT staging view is updated, very slowly, on the UI thread. The very slowly was fixed, but the premature UI lockout from updating a not-visible view was not. The GIT Staging View should NOT consume possibly non-trivial UI thread cycles when NOT visible.
Updating the UI may take some time (especially when thousands of changes suddenly appear as unstaged) and has the potential to block the user. Would be nice if that could be avoided, unless the user actually can see the view -- in that case we _have_ to update the UI.
(In reply to Thomas Wolf from comment #1) > Updating the UI may take some time (especially when thousands of changes > suddenly appear as unstaged) and has the potential to block the user. Potential, but there are solutions. For instance if in the standard Search View you do a search that find tens of thousands of results e.g. "http", the search results grow as results are found. The Search View shows an executing cursor. The other views are not frozen.
Technical notes: appears that this may occur in particular on IndexDiffChanges. Selection tracking already handles view visibility.
Created attachment 283378 [details] JProfiler screenshot while Staging View is updating tree view with 9000 items Similar issue here: Staging View does contribute more than 20 seconds to the Eclipse UI lock, when the input for the Staging View is getting updated (but not necessarily changed), for example by saving some additional change to some java file. Here, the git repository in question does consist of ~67000 files distributed to ~630 projects, with ~9000 files currently having Unstaged Changes. It turns out that the Staging View does initialize text and image to each of the ~9000 items into the TreeView, even if most of them never become actually visible. In total, the most expensive part here is in StagingEntry.getFile(), because for each of the ~9000 files, FileSystemResourceManager.resourceForLocation() does iterate over all ~630 projects to find some best matching project. Although I'm pretty new to Java and Eclipse, to me it should be possible to reduce the tree update time in general by using "virtual" tree views, and I have drafted something to see whether this may help: https://git.eclipse.org/r/c/165047 What do you think?
(In reply to Michael Haubenwallner from comment #4) > Created attachment 283378 [details] > JProfiler screenshot while Staging View is updating tree view with 9000 items > > Similar issue here: > Staging View does contribute more than 20 seconds to the Eclipse UI lock, > when the input for the Staging View is getting updated (but not necessarily > changed), for example by saving some additional change to some java file. > > Here, the git repository in question does consist of ~67000 files > distributed to ~630 projects, with ~9000 files currently having Unstaged > Changes. > > It turns out that the Staging View does initialize text and image to each of > the ~9000 items into the TreeView, even if most of them never become > actually visible. > In total, the most expensive part here is in StagingEntry.getFile(), because > for each of the ~9000 files, FileSystemResourceManager.resourceForLocation() > does iterate over all ~630 projects to find some best matching project. > > Although I'm pretty new to Java and Eclipse, to me it should be possible to > reduce the tree update time in general by using "virtual" tree views, and I > have drafted something to see whether this may help: > https://git.eclipse.org/r/c/165047 > > What do you think? You've picked a hard problem. Some thoughts: * The fact that this takes a lot of time is actually unrelated to the issue of this bug. (Though of course that it happens even when view is not visible isn't nice.) * Virtual trees may come with their own set of problems and bugs. The CommitFileDiffViewer (for instance bottom right in the history view) uses a virtual table, and we struggled quite a bit to make it perform for huge commits. * The selection handling when files are staged/unstaged is highly complicated, and may mean that all tree nodes get realized anyway. * To get decoration overhead out of the main thread: can these viewers be made to use a lightweight background decorator for all their decorations, or at least for the problem decoration? * (Small optimization) StagingEntry.getProblemSeverity() could return Severity.NONE right away if the state is REMOVED, MISSING, or MISSING_AND_CHANGED? * To reduce the number of calls to resourceForLocation() is there some way that we could cache project paths as we go, and subsequently look up projects in that cache first? If a project location is a prefix of the file location, the file should be in that project, and then determining the file via IProject.getFile() and checking if it exists may be faster. * According to your screenshot, the ProblemLabelDecorator accounts for some 30% of the time. Creating the tree items themselves also appears to be expensive, plus setting their images and texts (together another 30%). So perhaps a virtual tree is the way to go, but don't expect it to be easy. * Careful testing on all three platforms (Windows, GTK, OS X) will be needed.
(In reply to Thomas Wolf from comment #5) > (In reply to Michael Haubenwallner from comment #4) > > > > Similar issue here: > > Staging View does contribute more than 20 seconds to the Eclipse UI lock, > > when the input for the Staging View is getting updated (but not necessarily > > changed), for example by saving some additional change to some java file. > * The fact that this takes a lot of time is actually unrelated to the issue > of this bug. (Though of course that it happens even when view is not visible > isn't nice.) Agreed: Not updating the invisible view may make sense even if there were no performance issue. I've forked the general performance issue into bug 564569.
