Community
Participate
Working Groups
Filtered trees with a large number of items (on the order of a couple of hundred items) take too long to refesh after each keystroke (about 1 sec). We need to investigate this to see if we can fix the problem without having to add API to FilteredTree to change the refresh job's delay time. If that is not possible then we can add API so that client's can change the refresh job's delay time. See bug 74795 for more details of the problem.
I have released code that I think will fix the problem. I tested on a tree with 4000 items. Released into build > 20060228.
Karice, I would move 'treeViewer.getControl().setRedraw(true);' into a finally block to ensure that the widget is not completely broken if a content provider throws an exception.
Good suggestion, Markus - released changes for build > 20060301.
Refresh is improved. Verified in I20060512-0010
As per my commments on bug 74795, the performance of the current filtered tree refresh is still nowhere near where we need it to be for Mylar. If I type the letters 'the' in my task list with standard refresh mechanism my workbench will freeze for 10s or so. Details: - thousands of elements in a FilteredTree - 2Gig dual core, 2 Gig RAM We've addressed this by hacking in the adaptive refresh job described on 74795, which works great and without which we would probably need to remove the filter functionality. However, this approach is not supported by the API so I'm reopening this bug for us to discuss a solution. Some options: 1) Aallow the refresh job to be extended by subclasses and/or replaced (easiest) 2) Fill the contents lazily like Ctrl+Shift+R does. 3) Support something like the adaptive refresh that we implemented in AbstractMylarFilteredTree.textChanged()
The Extensions page of the plug-in editor could certainly benefit from a filtered tree. However, the performance is unacceptable when using a big plugin.xml like that of jdt.ui
It's the same with my filtered Navigator view. I think what would help if you delay the filtering based on keystrokes so that one can enter multiple strokes before the filter kicks off. Right now it kicks off after the first stroke.
Fyi Gunnar, I tested Mylar's filtered tree approach for a Navigator view (very similar to yours) with my full workspace in it, and the performance was almost there, but not quite. The current settings of AbstractMylarFilteredTree seem to work well for thousands of nodes but not for tens of thousands and up. Either the adaptation delay or curve could be changed to accomodate trees that large, or the filter could be changed to not invoke until Enter is pressed.
I like a combination of Mik's #1/#3 approaches. Let's do the 80/20 rule, cover the base with some of the enhancements Mik has suggested. And for people like Gunnar who like tree's with a gazillion items in them, they can add their own refresh strategy. I also created a bug to deal with using different type of viewers in the filteredtree (https://bugs.eclipse.org/bugs/show_bug.cgi?id=152170) Other than that, I love this filteredtree ;)
(In reply to comment #6) > The Extensions page of the plug-in editor could certainly benefit from a > filtered tree. However, the performance is unacceptable when using a big > plugin.xml like that of jdt.ui Indeed, see 3.3M1 (start typing "org" or "ecl").
it's pretty though Markus ;)
If anyone wants to contribute a patch to improve the implementation of the refresh of the FilteredTree I would be willing to take a look at it. The reason we didn't expose the implementation of the refresh job was for consistency so as to not frustrate users that saw and used filtered trees contributed by different components or products i.e. why does it work well in view A (contributed by one component/product) but not in view B (contributed by another component/product).
Regarding a patch, which approach do you think we should take of the ones I list in comment#5? Or another approach? I'm all for consistency. On the Project Explorer style prototype view prototype that I describe in comment#5 the 70 large projects I have in my workspace meant that, even with the adaptive refresh, this was more usable with delaying the refresh until I hit Enter. So I think consistency needs to take into account the size of trees that this will support, otherwise 'consistency' can mean mean instant response in one view and waiting 20s for a refresh to happen in another. So what size of trees should this scale to? Mylar's current needs are trees with columns that have thousands of elements, which the adaptive refresh is working well for. To make the adaptive refresh scale to Project Explorer size views I think it may need to take into account the number of items or be much more conservative. Or is it possible to fill the content lazily in the presence of a filter, as Ctrl+Shift+R does. That would scale gracefully no matter how big the tree.
It's hard to say what the best solution is, but in any case it needs to be scalable out of the box (i.e. clients should not have to fuss with it). For this reason I don't think allowing the refresh job to be extended or overridden is a good solution - also, it requires getting familiar with the filtered tree and Jobs that clients probably don't care to know about. Adaptive refresh can work nicely in some cases (as it currently does for your tree), but my fear is will we get it right for a large percentage of filtered tree scenarios (since we cannot anticipate how clients will use the filtered tree)? With regard to scalability (large scale), I am thinking 10000 packages in the Packages view, the Repositories view (the eclipse repo has lots of stuff), or any tree that shows all plugins in the target, which can get quite large for some downstream products - e.g. 2500 plug-ins. Taking the size of the entire tree into account is probably not going to boost performance because the entire tree needs to be traversed to get this number. On the small scale, the show view, preferences and wizards (new, import and export) should continue to function nicely. If you are willing to contribute the adaptive refresh policy you implemented I can give it a try with a couple of the large scale test cases I have to see how it performs. The possibility of lazily filling the contents, as in the Open Resource dialog, still needs to be investigated.
(In reply to comment #14) > The possibility of lazily filling the contents, as in the Open Resource dialog, > still needs to be investigated. To me this seems to be the only solution that really scales. I believe what you want is that the viewer scrolls to select the first match, and that the visible range fills up as quickly as possible to get stability into the UI.
+1 for lazily filling the contents as the only solution that really scales. What I've learned from trying the adaptive filter approach on the Project Explorer view is that the current "show all matches at once" approach works if you can instantly get all the contents of the tree. But on the tens of thousands of nodes trees this just isn't anywhere near fast enough on my Core Duo, and the UI hangs for part of the refresh. In spite of that I've also learned that I often still prefer this filter interaction to Ctrl+Shift+R, which is takes too many clicks if you're trying to find a common file like plugin.xml. Lazily filling should work great for sizes ranging from prefs/wizards to common navigators. Btw, I wonder if it is possible for some common navigator content providers to impose additional overhead when retrieving children (e.g. for computation, I/O, or network)? If we're filling lazily that's fine, and it just means that we might need to consider a "stop" button next to the clear button for cases where the job doesn't return instantly.
Created attachment 52369 [details] patch I have released this patch to HEAD >20061019. It improves the scalability of FilteredTree quite a bit, at the cost of not fully expanding all items in the tree if that takes too much time. If SWT gives us a way to expand a tree item without causing scrolling (see bug 159586), we will be able to continue expanding items in the background. It would be great if you all could give the improved FilteredTree a try and then comment on this bug.
(In reply to comment #16) > +1 for lazily filling the contents as the only solution that really scales. Unfortunately, unless SWT solves the issue in bug 159586, we cannot fill the contents from a background job without causing major flicker on Windows.
Team PDE loves you Boris
Just for the record, if this earns me love that's great, but I also consider it to be a part of the "search-based navigation" plan item. ;)
oops - I accidentally picked the wrong milestone
re comment 17, that was our finding too. For a while now, PDE has been using Janek's homegrown filtered tree which does not expand nodes. It works great and scales well. We will give the new filtered tree a whirl and migrate to it next week.
(In reply to comment #22) > For a while now, PDE has been using Janek's homegrown filtered tree Where can I find this? (in the UI, and in the code)
if I remember correctly, it's in org.eclipse.pde.ui.internal.commands.CommandList To see it in action: 1. Create a new cheatsheet. (File > New > Other... > User Assistance Cheatsheet) 2. In the Content section of the editor, select 'Item' 3. On the right hand side, in the 'Command' section, press 'Browse...' The dialog that comes up has the homegrown filtered tree.
My optimization didn't work on the Mac. I have released a newer version which should be in the upcoming nightly builds and in tomorrow's integration build. I would be interested in feedback. How bad is it for you when the filtered tree only expands the visible range?
See also bug 139798 for a similar discussion: we had some problems with our tree viewer filtering and tried FilteredTree.
Just fyi, I attempted to get rid of the Mylar Task List's adaptive refresh policy (comment#5) since refresh performance does seem a lot better and lazier now, and not expanding the latter nodes when there is a huge number of matches helps. It seems to work fine now without adaptive refresh on a Task List with one or two thousand items. Mine and some other users are a couple times that size and still cause freezes, so we're retaining the adaptive refresh for now. On 3.3M3 I noticed that the clear button would not always reappear when a long-refresh was kicked off, due to the return on FilteredTree.java:374 (Mylar bug 165353). For now we are working around this by explicitly invoking updateToolbar(true) in our overridden textChanged() method. Let me know if you want a bug report for this.
(In reply to comment #27) > Let me know if you > want a bug report for this. Yes please, do you have a patch as well?
Note that SWT has enabled more optimizations (see bug 159586) but I haven't had the time to make use of that yet.
moving target milestone as this bug is still open but set to M3.
I have filed two new bugs for potential future work: Bug 186424 [FilteredTree] Expand all remaining items in the background Bug 186425 [FilteredTree] FilteredTree does not scale to arbitrary numbers of nodes Marking this one as fixed in M3.
