Summary: | Staging View performance issue updating UI with thousands of changed files and hundreds of projects | ||
---|---|---|---|
Product: | [Technology] EGit | Reporter: | Michael Haubenwallner <michael.haubenwallner> |
Component: | UI | Assignee: | Project Inbox <egit.ui-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | jkubitz-eclipse, twolf |
Version: | 5.8 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=535681 https://git.eclipse.org/r/165363 https://git.eclipse.org/r/165364 https://bugs.eclipse.org/bugs/show_bug.cgi?id=519231 https://git.eclipse.org/c/egit/egit.git/commit/?id=b530c0dad1ed512d9259624498d599e41be1a28c |
||
Whiteboard: |
Description
Michael Haubenwallner
2020-06-23 04:37:37 EDT
One can indeed quite easily reduce the number of calls to FileSystemResourceManager.resourceForLocation() by simply creating the hierarchical model in the StagingViewContentProvider also for the flat list view, and then simply asking the containing StagingFolderEntry's IContainer, if it exists, for the file. (That StagingFolderEntry won't be shown, though -- it's a flat list view.) In my tests on OS X and in a Win 10 virtual machine showed indeed a speed improvement for the refresh of some 30%. Another problem is switching the presentation when a lot of items are selected. This takes quite some time on OS X, and is outright impossible on Windows. Switching from list view to tree view and back with all 9000 files selected causes the refresh on Windows to take forever (at least minutes; I always killed the process). This can be avoided by getting the selection first, clearing it, refreshing, then setting the selection again. I'll still have to test these changes on Linux, but if good there, I'll push two commits for these two improvements. That is not to discourage your attempts to use a virtual tree. Even with these improvements, refreshes with 9000 files take too long (about 9-12 seconds in list view, about 2 sec in tree view). New Gerrit change created: https://git.eclipse.org/r/165363 New Gerrit change created: https://git.eclipse.org/r/165364 (In reply to Thomas Wolf from comment #1) > Another problem is switching the presentation when a lot of items are > selected. This takes quite some time on OS X, and is outright impossible on > Windows. Switching from list view to tree view and back with all 9000 files > selected causes the refresh on Windows to take forever (at least minutes; I > always killed the process). This can be avoided by getting the selection > first, clearing it, refreshing, then setting the selection again. (In reply to Eclipse Genie from comment #3) > New Gerrit change created: https://git.eclipse.org/r/165364 Actually, this is bug 519231. Gerrit change https://git.eclipse.org/r/165363 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=b530c0dad1ed512d9259624498d599e41be1a28c (In reply to Thomas Wolf from comment #1) > One can indeed quite easily reduce the number of calls to > FileSystemResourceManager.resourceForLocation() Actually I'm wondering whether FileSystemResourceManager.resourceForLocation() itself really does have to sequentially iterate over all projects, even if some return value was already found. Feels like a topic for a different Eclipse project though. > That is not to discourage your attempts to use a virtual tree. Even with > these improvements, refreshes with 9000 files take too long (about 9-12 > seconds in list view, about 2 sec in tree view). Never mind: Getting the virtual tree ready may take some time actually, and any improvement available earlier is highly appreciated, thanks! |