Unanswered: GXT 3.0, performance issues
The first time I checked GXT 3.0 (a few months ago, it was still beta) it was quite slow. If you run the explorer demo 2.2.5 and 3.0 side by side and, for example, open "fast tree" tab. The new version performs about 5 times slower! It is sluggish. And my memory usage indicator noticeably climbs up. And the test is trivial. I simpy click to expand tree branches one after another.
Now the new version is out but the performance issue was not fixed. And I am not talking about 15% performance drop (and even that would raise a question in my mind - why the new version?). We are talking 500% performance degradation. One must be insane to migrate from 2.2.5 to 3.0 knowing how much the user experience will suffer.
BTW, does anybody know the new URL for the 2.2.5 Explorer Demo? It is no longer available and the old URL features version 3.0.
We would really like to fix any performance issue like this one. What browser are you using exactly and what OS? What are your computer specs?
Do you only have this huge performance issue in the fast tree example or also somewhere else in non tree examples?
Currently Tree uses way too many domquery interactions, we are going to look into this.
Ext GWT Premium Member
I can't say anything about the speed of a trees, but grids loads and display much faster than in version 2.2.5.
So I think, it is a tree issue.
It could be the Fast Tree. I just compared a few grids and they seem to perform similarly even though hovering over the rows renders a little faster (and feels a bit lighter) under 2.2.5.
I tested the Fast Tree in several environments:
Ubuntu 12.04, 64bit, Firefox 12
Ubuntu 12.04, 64bit, Chrome 18
Windows XP, IE8
Windows XP, Firefox 11
Windows XP, Chrome 18
The worst performance was on IE8 though the performance ratio "3.0"/"2.2.5" happened to be the best. It was less than 2 times slower for 3.0. Chrome performance was the best with the performance difference ratio "3.0"/"2.2.5"~=3 (3 times slower). Firefox was a bit slower than Chrome and its "3.0"/"2.2.5" performance ratio was the worst ~= 4-5 times slower (both Windows and Linux). Ubuntu box was much more powerful than XP but it didn't affect the relative performance differences between versions.
The IE also doesn't like too many nodes in a tree. As you expand a few thousand nodes in the fast tree (v 3.0) it brings the whole page (including the other open GXT Explorer Demo tabs) to a crawl and everything becomes sluggish. The same scenario in 2.2.5 doesn't do much damage to the overall page performance.
Testing other components via the GXT Explorer Demo didn't reveal any drastic performance differences. Fast tree is different in a sense that it allows to test larger volumes of data than most of other components. Live grid seemed to perform the same in both versions. The only difference for the other components that I noticed was when you move mouse over a grid or a tree it moves the highlight a bit slower in 3.0. It becomes more noticeable with more GXT Explorer Tabs open.
A small disclaimer.
I personally like a quite few things about v3.0. I like it is more native GWT compatible, I like the way you moved from accessing model fields by name to using provider interfaces, I like that when editing text now it treats "<xxxx>" as text and not HTML tags by default, etc. And I would gladly switch to 3.0 ...... but the noticeable performance degradation prevents me from switching at this time
Hopefully my small research can help you to identify and fix those issues.
It looks like it all comes down to mouse hovering over the tree/grid. In version 3.0 moving mouse cursor over any grid or tree is consuming 100% of CPU (100% of one core). This gets aggravated even more when fast tree has a few nodes expanded (meaning a few thousand nodes created).
Surprisingly scrolling over the fast tree is faster under version 3.0. It all boils down to tracking mouse hovering over grids & trees. The performance killer/bottleneck must be hiding somewhere in tracking mouse movement.
And the more nodes allocated - the more performance hit. It almost feels like there is a some kind of loop (which gets larger) in mouse tracking event handlers.
Sencha Premium Member
We are seeing similar issues specially with Grid selection and navigating to another tab with grids. Did you reach a conclusion for issues you saw at your end.?
vkeswani, the issues you've mentioned in other threads seem memory related, while the issues yurx mentioned are mostly CPU related - these were almost certainly caused by inefficient cell-finding code that was prevalent in early versions of the grid have mostly been changed at this point to be more efficient.
It may be that there are other improvements that can yet be made in that area, but in my testing this morning, mouse movements don't seem to affect memory usage in any meaningful way.
Sencha Premium Member
Thanks Colin - Yes the issues we are seeing are in IE8 browser. We can have mx of 1000 rows with 15 columns. With even 500 rows it is much slower and any kind of sorting or refresh operations on the grid cause browser memory foot prints to go up easily seen in task manager and browser refuses to release memory.
I can even recreate with gxt explorer by simply using IE8 and sorting example basic uibinder grid multiple times one after the other.