(RC 2) Web Mode Charting & Drawing Framework Performance
Release Candidate 2 shows a lot of improvement in this regard, but more is needed for IE (VML). Firefox (Sprite) seems to be doing alright with one caveat.
Some of the Flex charts we are replacing show ten series across 200 hours in less than 7 seconds. This is the most demanding use case we have.
Because GXT 3.0 performance has been improving with each release candidate, I figured it was an opportune time to prepare a column chart (ColumnChart_RC2PerformanceIssue.txt attached) that presented 200 days and deploy it to Tomcat for running in web mode.
When I bring up the chart using Firefox 7.0, the chart renders in 3 seconds and resizes in 6 seconds. This is great! The only issue with Firefox is that the browser window does not resize with the mouse as you drag part of the browser window, but the browser does change to the new size a few seconds later depending on where you stopped moving the mouse.
This same chart takes almost a minute to render in dev mode using Firefox, but for development work we can temporarily limit the time / category series axis to a more restricted range.
When I bring up the chart using 32 bit IE 8.0, it takes several minutes to render and even longer to resize. Please see attached screenshot (ColumnChart_RC2PerformanceIssue.png) that shows the IE long running script popup. I have to respond to the popup several times during both initial rendering and resizing.
I am using a Dell Precision M4500 that has 8 CPUs (1.87 GHz) and 8 GB memory running Windows 7 Enterprise 64 bit.
We're also observing some performance problems using IE9 and IE8 with the charts.
It's not an entirely fair test in our case though, as we're rendering a GXT3 chart within a GXT2 container.
On the screen that we're observing these performance differences, we're rendering two charts, Chart 1 has 1 bar series and 1 point series. 5 samples for each series. And a second chart with 1 bar series and approximately 100 samples.
The OFC based charts would take 2-3 seconds to render, but with the GXT3 charts it's taking 10-20 seconds. - not accurately timed, just seat of the pants observations.
Doing some testing I was able to track down major performance issues in axes with a large number of labels. The fix I just added to SVN had your example running about 4-5 times faster. I have also added an option in axis to set the ratio of labels displayed for how many tick marks.
I wanted to add a few more notes to this performance discussion, having worked a bit with Brendan on this specific issue, and other GWT/GXT projects. First, to reiterate from other threads that Dev Mode cannot be an accurate representation of production mode performance, for a variety of reasons. Some code will be faster, as it is run in pure (Store operations, perhaps), while anything that makes frequent calls into JSNI (to manipulate the DOM for example) will be quite slow.
The Surface implementations fall mostly into the latter category - every sprite is translated into a dom element for VML and SVG, and that requires writing values to the native JS objects. Each of these writes requires at least one call into JSNI, so this will be slow in dev mode.
Our primary focus at this point with regard to performance is the running web app - we wouldn't want to optimize in favor of dev mode if it might negatively affect production apps. GWT provides ways that we could have one implementation for production and another for development mode, but this then runs the risk of bugs that are only present in one of two modes.
The primary work done so far to optimize this has been to go after the low hanging fruit, the methods that are being called far more than is necessary, and have some cost associated with them - it turned out that some aspects of TextSprite rendering in VML were not very optimized, and with just a few test runs have allowed Brendan to make significant headway on this issue.
As you are both support subscribers, you should have access to SVN to check out these changes and see what we've come up with so far, and what other work still remains to be done. Make sure you measure in production mode though!
And a final note to troyg - mixing and matching containers shouldn't have much of an effect here, as long as you keep the resizing to a minimum - that requires redrawing the content, which is the killer here.
I'm unable to test the changes immediately sorry, as I've been re-prioritised with some other stuff in the short-term, but will let you know ASAP.
Also to clarify: I'm running the performance test in normal web-app mode. Though I am using the draftcompile option. I'll do a test with optimisations enabled with the latest from SVN as soon as I can.