Community
Participate
Working Groups
When a large array of elements is passed into DeferredTreeContentManager.addChildren (through IElementCollector.add(..)) the UI thread is completely blocked while the treeviewer is being updated. This nearly brings my entire system (Windows 2000) to a crawl.
Created attachment 14524 [details] test case (apply against org.eclipse.ui.examples.job) Apply this patch against org.eclipse.ui.examples.job. This will create a large number of SlowElement children to illustrate the problem. Start the runtime workbench and open the lazy trees view. Check the "batch returned children" checkbox. Open an item in the tree. The UI will block while the item displays "pending...".
The purpose of this deferred update is to only do a few a time - we do not control the amount that is sent and leave it up to the developer. Having said that we should add an upper limit to prevent his.
My impression is the bottleneck seems to be in the way the tree is populated. It calls AbstractTreeViewer.createAddedElement() for every element in the array and seems to spends an inordinate amount of time in indexForElement(). If I do as you suggest, and break up the array and pass it in smaller chunks, the UI is more responsive but the tree flickers a lot as elements are added. It also takes a VERY long time to populate the tree. When I use a normal content provider the tree displays quickly, I guess since the tree viewer calls contentprovider.getElements() directly and doesn't try to sort each element on insert as it does with AbstractTreeViewer.add(). I guess maybe what I would have liked is a "batch mode" deferred content manager. On the first call to getElements() it creates the "pending" item and runs the background job to fetch the children. When the job completes, the pending item is removed and essentially a refresh is done on the tree viewer - through some mechanism it is passed the completed elements array in one step (i.e. so it's treated the same as if getElements() had returned the complete array the first time).
There are currently no plans to work on this feature
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
