Bug 31698

I ran Sun's performance collector on the code tonight and saw that for
the scan, most of the time is taken by the PMD parse, followed by the
java parser parse job. These times together dwarfs the rest. Not much
I can do about that.

But I just now realized you're talking about explorer-performance for
a large number of tasks after the scan has completed. Yes, that's
probably a problem. Tonight I was investigating the TreeTableView to
try to help fix bug 30150, and I saw some pretty scary code in there;
the most scary one is probably getChild(): for EACH node in the
display, it will sort the list! And then iterate through the list to
find the nth child!!! I don't believe I need a performance collector
to guess where the performance problems are with sorting - that code
is definitely suspect. Here's the function - note how this gets called
repeatedly for every node to be shown:

        public Object getChild(Object parent, int index) {
            if ( ( sortedByProperty != null || sortedByName ||
noSorting ) && parent instanceof VisualizerNode ) {
                VisualizerNode n = (VisualizerNode)parent;
                java.util.List list = n.getChildren();
                sort ( list );              <======== SLOW; O(nlogn)
                return list.get( index );   <======== SLOW; O(n)
            }
            else
                return super.getChild( parent, index );
        }

Jirka, sorry :(

I'm going to see after when 30150 will be solved, at least in next
release.

fixed in main trunk, sort() is called only when sorting changed, not
from getChildAt(). An changed order in model is propagated to
VisualizerChildren, the tree model doesn't need to calculate each
child on given position. This fix will be merged to release35 together
with fix of issue 30150.

ugly performance problem, raised prio to P2 to make sure it will be
fixed in 3.5

fix merged to release35 branch

Tim L.,
can you verify this issue?

Thanks in advance.

It's about 10 times faster now. Thank You.