PDA

View Full Version : TreeLoader/ TreeStore slowness



petko.ivanov
3 Jun 2010, 7:17 AM
hi,
there are quite a lot of posts about slowness when working with trees.
The usual symptom is a pop-up message in IE that complains the script is taking too long. Firefox seems fine but is actually still taking a long time.

petko.ivanov
3 Jun 2010, 7:20 AM
i just saw :
http://www.extjs.com/examples-dev/explorer.html#fasttree
so will try this next and report results.
btw for comparison - my tree size is about 450 leaf nodes.

sven
3 Jun 2010, 7:22 AM
You could have used the forum serach. GXT 2.2 will contain many improvements for this as discussed about 100 times in the last month. Your suggested fix brakes much functionality. I will remove that code from the post

petko.ivanov
3 Jun 2010, 7:46 AM
i did search - could not find anything relevant. Also the fasttree is not really relevant to me as i am interested in the TreeGrid component. The above is the only way i could get TreeGrid to be actually usable in IE.
When will GXT 2.2 be available, where can i see a demo please?
just out of curiosity - what functionality does this break?

sven
3 Jun 2010, 7:48 AM
The changes will also improve TreeGrid. GXT 2.2 is planned to be released this month.

The changes will be in SVN very soon

petko.ivanov
3 Jun 2010, 7:55 AM
ok, i can retest my use case as soon as 2.2 is out.
However, my code needs to be deployed asap (as usual) so the patch i posted is the only solution i have at the moment. If u can propose anything better , i would be happy to try it.
I definitely understand if u think the code is no longer relevant so no need to incorporate it but you should put it back for the benefit of users in my position.

sven
3 Jun 2010, 7:56 AM
but you should put it back for the benefit of users in my position.

Your code can brake functionality. That is why i removed it. It should not be advertised as fix for slowness.

petko.ivanov
3 Jun 2010, 8:25 AM
the rationale for my fix is as follows:
1. when nodes are inserted, their children are added with suppressEvents flag = false (hardcoded). at a minimum it should be the value of the suppressEvents flag of the caller. If i dont want events for the parent, why would i want events for the children? does not make sense.
2. actually if you think about it again, even if u do want events generated for the top level nodes i am inserting, i dont see why i would need events generated for their children (and grandchildren) as they are not visible yet. Once they become visible, the proper events are generated anyway so all works as expected.
I can see why/how the current version works but it errors on the side of safety by generating too many events and as a direct result of this slows insertions of even a few hundred elements to the point that its not really usable. If people cant use IE , then i am sorry but it simply does not work. IE currently pop this warning, stop the script execution and the treestore is incomplete. My code only generates events for elements that are visible. If you have a test case where these events are actually required i can admit that my code will not work for them but frankly i dont have such a case. I suspect most users dont, so they should be fine to use this code too.
Removing the code is a bit too aggressive on your side. At worse it only fixes a specific use case, at best it fixes a general bug. Users still have the choice to use whichever TreeStore they want.

sven
3 Jun 2010, 8:29 AM
. At worse it only fixes a specific use case, at best it fixes a general bug. Users still have the choice to use whichever TreeStore they want.

And exactly this is the problem. They simple use it without thinking about it and even forget, that they use it. We run into too many problems with this already.
Check your pms.

sven
3 Jun 2010, 8:36 AM
2. actually if you think about it again, even if u do want events generated for the top level nodes i am inserting, i dont see why i would need events generated for their children (and grandchildren) as they are not visible yet. Once they become visible, the proper events are generated anyway so all works as expected.

TreeStore is not linked to any component. Also if component X may not display the items yet. You want the info somewhere else.

Else let me ask you this question. If you are not displaying the items yet, why do you add them? It is just data that sits in the memory and is uneeded at this point

petko.ivanov
3 Jun 2010, 9:36 AM
in the terminology of that method call: When children (1) are added, they will actually become visible immediately after the add (so events are needed). Their children(2) however are still invisible (as their parents=marked with 1) are still collapsed. That's what i meant.
If at a later point in time, the 1 get expanded, the nodes underneath (marked with 2) will show fine (even though at the time of insertion no events were generated for them).
let me pm you my number if u want to discuss offline.

sven
3 Jun 2010, 9:47 AM
In a treestore nothing is collapsed or expanded or anything. You cannot think like this if you want to fix issues. I dont have time to discuss this any further, but you need to see the treestore on its own and not coupled to a widget, that may only render some of the items that are part of the store.

petko.ivanov
3 Jun 2010, 9:57 AM
i was using the terms collapse/ expand to describe the visual state of the tree.
I _HAVE_ fix the problem for myself, confirmed by me and users in multiple browsers. My secondary hope was to share this with a handful of others suffering from similar symptoms.
If any users want to try it, pm me. At this point, nothing more i can do.

sven
3 Jun 2010, 10:01 AM
A treestore has no visual state. I think you are not understanding it. Only because something is not yet displaying the data inside the store, does not mean the data is not needed or your application does not need to know the correct state.