PDA

View Full Version : Performance Performance Performance



darrellmeyer
22 May 2008, 7:29 AM
As many of you know, in certain areas, GXT performs noticable slower than Ext JS. Improving performance has been a high priority. There have been some new changes I wanted to share.

TabPanel
TabPanel has been improved in 3 places.

1. TabItems are now only rendered when the tab is selected, not when it is added.
2. When switching tabs, the active tab does not execute its layout if it has already been rendered and the size of the panel has not been changed.
4. CardLayout, which tab panel uses, now will only render the active child.

With the new code, the tab panel renders faster, and tabs are added quicker. The most noticeable change is when switching tabs, which now happens with no delay. Also, the scroll state of tab items is now preserved when swithing between tabs

BoxComponent
BoxComponent calls onResize whenever it is resized. Many subclasses recalculate their internal layout by overriding onResize. The call to onResize now only occurs if the the size since the last resize has changed. So if a component is resized to by 100 by 100 onResize will be called if. If the comonent is resized again, with 100 by 100, onResize will not be called.

I have put the explorer demo online with the new code. Take a look here:

http://extjs.com:8080/explorer2/#overview

We will continue to work on improving performance as there are still places that can be optimized.

gslender
22 May 2008, 1:04 PM
Darrell, I believe you know this, but table and tree are killing me (us)... I guess this won't be resolved until you start the replacement code (aka Grid)...??

True?

abickford
23 May 2008, 6:32 AM
If you go to http://extjs.com:8080/explorer2/#tabpanel in FireFox and scroll a little bit in the first tab, there are some serious refresh issues. The slower the scrolling, the worse it is. Seems ok in IE (7).

abickford
23 May 2008, 6:35 AM
If you go to http://extjs.com:8080/explorer2/#basictable in FireFox, hide a column and then show it again, the table is in an unusable state. For example, if you hide the column "last" and then hide the column "change" then try to set "last" visible, followed by setting "change" visible, you end up w/2 header rows.

abickford
23 May 2008, 6:37 AM
It appears http://extjs.com:8080/explorer2/#treetable suffers from the same column problem.

darrellmeyer
26 May 2008, 12:38 PM
There were some big changes made to layouts recently. This has resulted in much faster performance and rendering. The explorer2 code has been updated.


If you go to http://extjs.com:8080/explorer2/#tabpanel in FireFox and scroll a little bit in the first tab, there are some serious refresh issues. The slower the scrolling, the worse it is. Seems ok in IE (7).Looks like a firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=361768. I am trying to find a fix.

If you go to http://extjs.com:8080/explorer2/#basictable in FireFox, hide a column and then show it again, the table is in an unusable state. For example, if you hide the column "last" and then hide the column "change" then try to set "last" visible, followed by setting "change" visible, you end up w/2 header rows.Fixed.

It appears http://extjs.com:8080/explorer2/#treetable suffers from the same column problem.Fixed.

sheesh-kebab
30 May 2008, 1:17 PM
it seems like performance is getting better (at least it's getting snappier on my dev 4cpu 8gig system :) ). seriously, explorer2 preview is noticeable faster than what I remember.

sheesh-kebab
10 Jun 2008, 4:19 PM
this past week I got a chance to use somewhat slow non-us broadband internet connection. Of course, I couldn't resist and hit a few GWT apps to try out their performance - including GXT explorer demo. Unfortunately, performance of the GXT Explorer demo was rather poor - and from what I saw mostly related unoptimized css and image download (absent use of image bundles for various controls and unoptimized css and lack of expires header (http://developer.yahoo.com/performance/rules.html#expires) ).

I think it would be worthwhile to take a look at some of these issues in the next round of optimizations...

zaccret
11 Jun 2008, 10:06 PM
I have also noticed the absent use of image bundles. I guess it would be a great performance improvement to use these.

Maerch
20 Jun 2008, 2:29 AM
Unfortunately the 'explorer2'-demo isn't online anymore.

I am trying to evaluate this framework for our company, so i have two little questions about this issue:

* Darrel, do you believe that the Ext-GWT performance will be comparable to Ext JS's or will it have always performance "problems" because of the nature of GWT?

* If you believe that it could be performant, what do you think when you will achieve this goal. Are you trying to pool your strenghts to adding features to be comparable to EXT JS in the 1.x versions or will be the performance the bigger issue for you?

Thank you!
Maerch

darrellmeyer
20 Jun 2008, 5:48 AM
Unfortunately the 'explorer2'-demo isn't online anymore.Explorer2 was temporary. The current code runs at http://extjs.com/explorer.


* Darrel, do you believe that the Ext-GWT performance will be comparable to Ext JS's or will it have always performance "problems" because of the nature of GWT?GWT 1.5 does some amazing things when it comes to performance and code size. In many cases, the compiler can create faster, and more efficient code that you could write your self. I would recommend at taking a look at the screencast (http://www.youtube.com/watch?v=vv2MnqP8Bmk) from Google IO, where GWT performance is discussed.

The GXT library itself, had many areas that did not perform well. Most of these places have been fixed. If you take a look at the Explorer Demo, you will find things are much quicker and perform at the same level as Ext JS.


* If you believe that it could be performant, what do you think when you will achieve this goal. Are you trying to pool your strenghts to adding features to be comparable to EXT JS in the 1.x versions or will be the performance the bigger issue for you?There is still room for improvement, but the current code performs well. The Table is the notable exception, however, it is being refactored for 1.1. Out goal, is to match the features of Ext JS 2.0 as quick as possible. You can see our road map (http://extjs.com/products/gxt/roadmap.php) for more details.

Ronn
22 Jun 2008, 9:22 PM
Hi Darrell,

I started with gwt-ext and have converted to GXT for about a month now. I must say that (with exception of gwt rpc) the performance and features lag far behind gwt-ext.

The way I see it is that there are two fundamental differences,
a. gwt-ext that wraps ext-js javascript
b. gxt that generate javascripts from GWT.

Am I right to assume that you believe that GXT approach will eventually yield a better outcome in terms of performance? If not what are the rationale for your approach?

Mean while I'm patiently waiting for table grouping feature :) and very envious to what is now available in GWT-EXT.

darrellmeyer
23 Jun 2008, 7:10 AM
Excluding Table, where are your concerns with performance? Grouping and totaling will be part of the next Grid in 1.1. Take a look at out roadmap (http://extjs.com/products/gxt/roadmap.php).

michaelosity
23 Jun 2008, 8:46 AM
I have a page that uses various FormPanels and has about 100 fields scattered across 10 or so FormPanels. The render speed of that page on Firefox 3, Vista, 2.2Ghz dual core w/ 4G of memory takes about 3 seconds. In Firefox, each row of fields on the panel visibly "pops" onto the page. It's quite distracting. IE/Safari/Opera all wait and render the entire page at once so while there is a 3 second or so lag (during which time there is no indication of what is going on), the page renders cleanly.

This may be an extreme case (and it may be that GWT itself would render similarly), but it is way below my expectations. Using the latest webkit builds from Apple the page renders almost instantly, so I'm guessing this is a JavaScript execution speed issue?

Do you have any test suites that have 100s of fields? Most of the examples you show in the demo online are quite simple examples that do not stress the framework the way I think most users will or at least the way I'm doing.

Is this something that we can expect will get better with 1.1 or is this just a fundamental problem with the framework? The render speed as it is now is unacceptable to deploy to real users for me.

-m

Ronn
23 Jun 2008, 3:10 PM
Excluding Table, where are your concerns with performance? Grouping and totaling will be part of the next Grid in 1.1. Take a look at out roadmap (http://extjs.com/products/gxt/roadmap.php).

Yup have seen the road map and eagerly waiting for that.

I guess in terms of performance, the collapsible panel in the explorer demo is an example. It is comparatively slower than gwt-ext (even without animation). Also when I watch my cpu usage, gwt blips up more just to collapse the panel. Layout seems to consume more resource and slower.

I don't have a concrete benchmark it's just a feel when you play with each of the framework.

Btw: My real question is that there seems to be two approach in building this framework for GWT and there are two competing product out there that implements it in a different way. I'd like to get your insight on the architectural decision with GXT.

The question I am asking myself is this: from technical perspective (ignoring market forces) in the long term will I be better off with a EXTJS wrapper? or a complete ground up like GXT. I assume you must believe that GXT approach is better that is why you are doing it but why is it better??

zaccret
3 Jul 2008, 10:00 PM
Have you considered the use of GWT ImageBundles instead of CSS for icons ?