Problem with Tree performance

[Bill C.]

Hello GWT gurus,

I have an application that uses a Tree. When expanding a node of the
Tree I make a server call to find the items to populate the next level
of the tree. The server call returns relatively quickly. If there
are relatively few (say 1-100) items to add to the TreeItem just
expanded, everything seems to perform reasonably well. However,
sometimes there are 100s of items returned from the server call (maybe
up to 1000 sometimes). In these cases it just takes forever to
populate the tree and have it display. The performance is so bad it
makes the application unusable.

Also, I have noticed that on some workstations, the CPU usage pegs
during the population of the tree. I've got a pretty fast workstation
myself, and it takes up maybe 50% of the CPU. This will make it
difficult for our clients who may not have as fast of a workstation.

Has anybody else encountered this issue before? If so is there a
known solution or workaround?

Any help greatly appreciated. Thank you in advance.

We are using GWT version 1.4.61.

Bill

[gregor]

Hi Bill,

If you look at the TreeItem code you will see that you will see that
each node is rendered as HTML:

// Uses the following Element hierarchy:
// <div (handle)>
// <table (itemElem)>
// <tr>
// <td><img (imgElem)/></td>
// <td><span (contents)/></td>
// </tr>
// </table>
// <span (childSpanElem)> children </span>
// </div>

Building 1000 of these is a lot of work for the browser, can take
seconds and may render the tree unusable as you say . Try a simple
example program to demonstrate this. I think you should ask yourself
what use a tree node with 1000 children is to a user and maybe look at
a different approach to display the information. Normally where a
server call might return 1000 items for display one would introduce a
paging/filtering system of some kind, but that's not easy with a Tree,
so maybe Tree is not the right Widget for your task at hand or it
needs to be used in conjunction with something else to take care of
the "big ones".

regards
gregor

[Bill C.]

Gregor,

Thanks for the reply. The problem is that for most of the cases, the
Tree widget is perfect for what we do. We have heirarchical data that
needs to be browsed that fits very nicely into a Tree format. The
1000 items is kind of the worst case and is fairly rare. However,
there are a fair number of places where we have say, 2-5 hundred items
and these take forever to render as well. We have the Tree inside a
scrollable window so when we have a large number of child TreeItems
like this it's really not all that hard to just scroll up and down
looking for the item you're interested in. So I don't think the large
number of items necessarily means we shouldn't be using a Tree.

One thing I've discovered since my original post is that Firefox seems
to do a much better job. For my original post I had been using IE 6
(I've since tried IE 7 but it is no better in this respect than IE
6). Firefox is still fairly slow but probably say, 5 times faster
than IE which makes it usable (but barely). Unfortunately we can't
require our clients to use a specific browser. Is there any known
reason why Firefox does such a better job? Does it just have a much
better JavaScript interpreter or something?

Is there really no other known work around for this? Has anybody else
encountered this before? I'd be very interested to know what kind of
solutions others have used to get around this limitation.

regards,

Bill

> > Bill- Hide quoted text -
>
> - Show quoted text -

[stuffed]

Bill,

We have encountered the same issue with the application we are
building. We have a data tree that represents data in a hierarchy.
The tree is dynamically loaded and for most items it works just fine
as there aren't very many items to load. However, a few of the
hierarchies have many sub-items (1000+) and the browsers hang.

We haven't solved this problem however we have noticed the following:
* The Javascript interpreter used makes a huge difference. Firefox
will load the tree items relatively quickly using a limited amount of
memory. Safari (mac & windows) is even better. IE 6/7 is the worst -
it consumes the most cpu and memory to the extent where it will
consume all the memory on my computer.

* Adding items to the tree using a deferred command helps improve the
user experience (see example below). This allows for the browser to
process other events while the tree is still loading and not
completely hang. We also added the % loaded that is updated with each
deferred command so the user can see how slow/fast the loading is and
when it is expected to finish.

private void deferLoadTreeItems(final Iterator it) {
DeferredCommand.addCommand(new IncrementalCommand() {
public boolean execute() {
//add items 10 at a time
for (int i = 0; i < 10 && it.hasNext(); i++){
addTreeItem(it.next());
}
//repeat until no more items
return it.hasNext();
}
});
}

* In our application we added a search function that allows people to
search for a particular data item. If a user knows the name of the
particular layer they are looking for they can search for it and see
just the single layer. This helps the user, but does not solve the
issue.

Emily

On Jun 23, 7:46 am, "Bill C." <billche...@yahoo.com> wrote:
> Gregor,
>

> Thanks for the reply.  The problem is that for most of the cases, theTreewidget is perfect for what we do.  We have heirarchical data that
> needs to be browsed that fits very nicely into aTreeformat.  The

> 1000 items is kind of the worst case and is fairly rare.  However,
> there are a fair number of places where we have say, 2-5 hundred items

> and these take forever to render as well.  We have theTreeinside a

> > seconds and may render thetreeunusable as you say . Try a simple

> > example program to demonstrate this. I think you should ask yourself

> > what use atreenode with 1000 children is to a user and maybe look at

> > a different approach to display the information. Normally where a
> > server call might return 1000 items for display one would introduce a
> > paging/filtering system of some kind, but that's not easy with aTree,

> > so maybeTreeis not the right Widget for your task at hand or it

> > needs to be used in conjunction with something else to take care of
> > the "big ones".
>
> > regards
> > gregor
>
> > On Jun 20, 7:09 pm, "Bill C." <billche...@yahoo.com> wrote:
>
> > > Hello GWT gurus,
>

> > > I have an application that uses aTree.  When expanding a node of the
> > >TreeI make a server call to find the items to populate the next level
> > > of thetree.  The server call returns relatively quickly.  If there

> > > are relatively few (say 1-100) items to add to the TreeItem just
> > > expanded, everything seems to perform reasonably well.  However,
> > > sometimes there are 100s of items returned from the server call (maybe
> > > up to 1000 sometimes).  In these cases it just takes forever to

> > > populate thetreeand have it display.  Theperformanceis so bad it

> > > makes the application unusable.
>
> > > Also, I have noticed that on some workstations, the CPU usage pegs

> > > during the population of thetree.  I've got a pretty fast workstation

[Bill C.]

Emily,

Thanks. I will look into the DeferredCommand. I was not aware of
this class. This is exactly the type of feedback I was looking for.

BTW, one thing that I have noticed is that it doesn't seem to me to be
a "rendering" problem per se. From my testing it appears that the act
of instantiating the child TreeItems and adding them to the parent
TreeItem is what is causing all the delay. They do not need to be
displayed or rendered at all to observe the delay. E.g. one solution
I have been experimenting with is to divide large groups of child
TreeItems into sub groups of 20, each of which would be contained in a
parent TreeItem whose label is of the form: "<1st child item> - <20th
child item>".

E.g. suppose you have following child items: Adam, Bob, Carol, ... (16
more items in alphabetical order) ... Mike, Nancy, Oscar, Patty... (16
more items in alphabetical order) ... Zack (total of 40 items). The
first time you expand the parent TreeItem for this list it would look
like this:

- Parent TreeItem
+ Adam - Mike
+ Nancy - Zack

If you were to expand "Adam - Mike" and "Nancy - Zack" it would look
like this:

- Parent TreeItem
- Adam - Mike
Adam
Bob
Carol
...(16 more)
Mike
- Nancy - Zack
Nancy
Oscar
Patty
... (16 more)
Zack

In other words, I artifically created a "faux" layer in our data
hierarchy to limit the number of items at that level. But what I
found was that it didn't matter. Even before I expanded "Adam - Mike"
and "Mary - Zack", it still took a very long time just to populate
their respective TreeItems. When I did click on them to expand them
they were displayed almost instantly. So it seems to me that the time
is not being spent "rendering" things as much as it is populating the
DOM object.

BTW, I concur with your observations on IE 6/7 and Firefox (haven't
tried Safari). Another thing I've noticed about IE is that it does
not give the memory back. I can close my pop-up window containing my
Tree and the memory usage for my IEXPLORER.EXE process does not go
down. Then the next time I bring up my pop-up with the Tree in it, it
starts using even more memory. I haven't used it long enough to see
if the process will eventually die, but if that trend continues like
that I don't see how it could not.

Bill

> > > - Show quoted text -- Hide quoted text -

[Amr]

Hey Bill,

Are you pre-loading the 'next' level of the tree?

Given your tree in our scheme,

- Parent TreeItem
+ Adam - Mike
+ Nancy - Zack

We wouldn't load the children for 'Adam-Mike' or 'Nancy-Zack' until
the user actually tried to open up that branch.
When you open up 'A-M' we'd only load up those items. That way we
split the work to be done over two periods. 500 at a time, vs 1000 all
in one shot.

And yes, it's not the graphics rendering, it's adding the items to the
DOM that's time consuming. And in some browsers memory consuming.
I'll add to the browser discussion that Opera, much like Safari, has
no problems with large tree items and no memory issues.

So far, our best solutions to this problem are to split things up as
you've mentioned with faux layers, and allowing a search.
Our search returns branches that match the search criteria. Those
branches can be opened up (they are tree items) and would then show
their children just like they would in the original tree.

Amr.

[Bill C.]

Amr,

Yes, I was populating the "next" level as well. I didn't realize at
the time that it was the populating of the TreeItem that was taking
all the time. I thought it was the actual rendering of the HTML in
the browser that was the bottleneck. Now that I realize that, though,
I agree the next step is to defer the populating of the "next" level
until the user goes to expand it.

thanks,

Bill