Community
Participate
Working Groups
Created attachment 269217 [details] profiler screen shot * have git staging view in list presentation mode * delete 2000 files * select all files in the git staging view * switch to tree or compact tree presentation in git staging The UI is blocked for nearly a minute on my machine. The effect depends on the number of selected file (i.e. if just 1 of the 2000 files is selected, the switch is nearly immediate). However, as far as I can tell from a quick profiler run, all the time is spent in jface, nothing in egit itself (see screenshot). Therefore I'm not sure if anything can be done in egit except for putting the refresh into a job for not blocking the main thread anymore.
Well... the refresh is in a syncExec and inside a setRedraw(false), so I don't see how it could be moved off the UI thread. But clearing the selection before the refresh and restoring it afterwards fixes this. Overall performance of these viewers is still fairly bad when there are several thousands of items.
I'm somewhat sure that I have half-baked code lying around that adds a second version of AbstractTreeViewer.expand() usable for a collection of items, thereby removing the overhead causes by repeatedly visiting the (identical) parents and repeating the same code there. Have to find that machine and repository...
As I saw it in the debugger, the problem is that the TreeViewer tries repeately to restore an ITreeSelection containing TreePaths that just don't exist anymore. That just explodes. That's why the new code makes sure to restore the selection using the objects selected, not their tree paths.
Is the non existence of the old tree paths something caused by our usage of the treeviewer or is that a general problem for all tree viewers? Basically I'm wondering if your "workaround" can be applied to AbstractTreeViewer.refresh() as such.
It's caused by switching the layout. Tree layout: folder/file list layout file These are two rather different paths. When you switch from tree to list (the more expensive case in my tests), the viewer looks for the second component first when it tries to restore the old selection that still contains the paths from the tree layout. It doesn't find it and asks the parent "folder" to create the child. So it tries to find "folder" and doesn't find that either. I didn't debug in depth to see if there might be a simple fix somewhere in TreeViewer for such cases. (Wouldn't help EGit anyway, since it needs to be able to work on older platforms.) But once I saw that, it was clear how to avoid this problem. (We already have a special label provider in StagingView to avoid problems with tree paths.)
Gerrit change https://git.eclipse.org/r/165364 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=07aa153f5d35215f6a7394edf6936c394507085d
