Community
Participate
Working Groups
If I pull up the outline popup (Cmd-O) and start typing, it takes anywhere from 5-10 seconds for the typing to complete and the filtering to take effect. This is on a large class with ~ 200 members - Its not as slow on smaller classes, but still some lag noticeable. eclipse 3.2RC2 on OS X 10.4.6 java 1.4.2_09
This works for me using large classes like TextLayout.java or JavaEditor.java. André how's the performance for you? Matthew, please provide a concrete example.
On my 2 GHz Dual Core Intel Mac, I don't see any delays...
My machine is _just_ a Powerbook G4 1.67GHz :) The delay only happens when the _filtered_ list is large, i.e. a class with many gettters and you type get as the filter text - the g types fast, but the e and the t take a while to appear, and so on if many of the getters have similar names - I have many getD... so the D takes a while to appear too.
From comment 1: >Matthew, please provide a concrete example.
Created attachment 40195 [details] project containing concrete example Unzip the project, point to it in eclipse, open Baz.java, hit cmd-o, type getme to filter, notice how slow the typed letters appear.
reopened with concrete example.
I do not have a computer that is as fast as André's and the attach test case works extremly smooth. Did you try with fresh Eclipse SDK 3.2 RC2 and fresh workspace? André, just to double-check: can you give the attached example a try?
Yes, I can confirm that there is a noticable delay (0.5 sec) between chars on typing "getMe". (However, it is still 100x more responsive than typing in the SpotLight dialog on Tiger :-)
I see a much more severe delay when opening the outline on class OS (the Mac SWT natives). Whenever you type a character that results in a drastic change of filtered TreeItems, the delay is noticable. IIRC, this is probably the old Mac problem that creating single TreeItems takes way too long. I could verify this if you (Dani) can show me how to disable the Tree update on typing.
OK, problem seen. We should switch to use the FilteredTree in 3.2 which should get rid of that problem.
>We should switch to use the FilteredTree in 3.2 which should get rid of that >problem. I meant 3.3.
Setting to remind until blocking bugs are fixed.
Dani, see my question in bug 133378#c2.
We can now "use" the FilteredTree but run into problems like - layouting: we add a view menu and have to see how to get the alignment right - our key listener seems to be overridden/hidden by the one attached to the text widget - we need to change the text widget creation in order to get rid of the border - in a normal sized scenario the tree filtering now looks slower due to the delay Before we go down this path I'd like to let André test a prototype to see whether switching to the FilteredTree would solve the initial problem reported in comment 0.
- plus we need to add a horizontal separator between the text and the tree
1. Are you using filtered tree in a view? What is it about the alignment that is not right? 2. I didn't anticipate clients to wanting to change the behavior of the listeners - the behavior should be as consistent as possible across all filtered trees. Is the behavior you want to add something that should be added to all filtered trees? 3. Overriding doCreatefilterText() should resolve this 4. Performance - see bug 128233 (suggested patches welcome). 5. Does overriding createControl() accomplish this?
Karice, my previous comments were not meant to list problems in the FilteredTree itself but just list the (considerable) work we have to do when we want to switch. I think most of it can be done (the exception being the layouting). I added you because you might be interested to hear how it goes. >1. Are you using filtered tree in a view? What is it about the alignment that is not right? No, I tried to use it for our Quick Views (e.g.Ctrl+O ) which are PopupDialog's. The thing which is currently almost impossible to do is to put the (private) horizontal line between the text and the tree widget. I'll file a bug report if we decide to go ahead with this PR once we have the performance feedback from André. >2. I didn't anticipate clients to wanting to change the behavior of the >listeners - the behavior should be as consistent as possible across all >filtered trees. Is the behavior you want to add something that should be added >to all filtered trees? No, we add a key listener to the tree and the text widget in order to allow closing the dialog upon ESC and to provide the toggling (you can press Ctrl+O again while it is open to see the inherited members). We just have to attach them to the FilteredTree's widget and should be fine. >4. Performance - see bug 128233 (suggested patches welcome). I'll let you know how it compares to our current solution. What worried me more is the fact that it feels slower in general i.e. also when having just a few items.
Created attachment 50990 [details] Quick hack using FilteredTree André can you comment on the performance of this patch (compared to comment 9)? It applies to R3.2 and newer.
André?
I could not get the patch to work because init() is no longer available and doCreateTreeViewer() is called from the constructor of the super class FilteredTree, which makes it hard to set fControl early enough (thus avoiding the NPE).
Using I20061003-0800 I see a FilteredTree.init method but with 2 parameters: (int treeStyle, PatternFilter filter). You can simply remove the unneeded one and it should work.
Ok, I got this to work. However, I see very mixed results (on a 2.0G Intel Dual Core Mac Book Pro): I tested Ctrl+O with SWT carbon's OS class. Old version: typing 'q': filtered result with almost no delay typing backspace: 5 second delay until tree is unfiltered again New version: typing 'q': 2.5 seconds delay until filtered result ready typing backspace: 0.8 second delay until tree is unfiltered again Old version: typing 'k': 2.5 seconds delay until filtered result ready typing backspace: 3 second delay until tree is unfiltered again New version: typing 'k': 2 seconds delay until filtered result ready typing backspace: 3 second delay until tree is unfiltered again So overall the old version seems faster on filtering, the new version faster on un-filtering.
André, can you also try with a small (or average) sized CU? On WindowsXP I see delays with the new version which results in a worse UI compared to the old one.
I tried with smaller files and/or I tried typing more than one letter in row. On Mac the current solution feels more smooth and more responsive so I' suggest to keep using it. The only thing that works better in the new code is when deleting all characters from the filter so that the Tree has to populate the full tree.
Pressing the backspace takes that long because - all items (> 2500) need to be created (about which we can't do much) ==> switching to use virtual tree could solve this issue. - bug 161400
Boris, what was the result of using the virtual tree in the large tree viewer example?
(In reply to comment #26) > Boris, what was the result of using the virtual tree in the large tree viewer > example? I think the underlying problem is that we call refresh() to refresh the whole tree when the filter text changes. This is a blocking operation that takes a long time for medium and large trees. We need a way of refreshing the tree incrementally, in the background. I ran into a problem with SWT's TreeItem.setExpanded which scrolls to the item that is expanded. Because of this, my first attempt at making FilteredTree scalable didn't produce useable results, and then I had to focus other things. But it's still on my to do list.
You should try the filtered tree again now that Boris has made some performance optimizations to it - see bug 128233. If you have any comments on the new optimizations put them in that bug.
Not sure if FilteredTree in its current state is helping much - the main optimization was to not expand elements that are outside of the visible range. This helps for deep trees, but not for cases like Ctrl-O on classes with many menmbers like OS.java.
Get rid of deprecated state.
.
Changing OS from Mac OS to Mac OS X as per bug 185991
