Thank you for reporting this bug. We will make it our priority to review this report.
  1. #1
    Ext GWT Premium Member
    Join Date
    Oct 2011
    Posts
    99
    Vote Rating
    0
    LEWJO10@ca.com is on a distinguished road

      0  

    Default (RC 2) Web Mode Charting & Drawing Framework Performance

    (RC 2) Web Mode Charting & Drawing Framework Performance


    Brendan,

    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.

    Please let me know your thoughts.

    Thanks,
    John L
    .
    Attached Images
    Attached Files

  2. #2
    Ext GWT Premium Member
    Join Date
    Apr 2009
    Location
    Hamilton, New Zealand
    Posts
    30
    Vote Rating
    0
    troyg is on a distinguished road

      0  

    Default


    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.

  3. #3
    Sencha - GXT Dev Team BrendanC's Avatar
    Join Date
    Aug 2010
    Posts
    534
    Vote Rating
    3
    BrendanC is on a distinguished road

      0  

    Default


    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.

  4. #4
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,717
    Vote Rating
    89
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    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.

    IE displays the slow running script message when a certain number of operations has been performed in a given event loop, meaning that too much code has been run, so the browser is giving up. Because this is a fixed number of operations and not a timeout, a slow machine might give the error at the same time as a faster machine. The differences in how dev mode and compiled javascript run will also mean that this error will show up differently in each.

    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.

  5. #5
    Ext GWT Premium Member
    Join Date
    Apr 2009
    Location
    Hamilton, New Zealand
    Posts
    30
    Vote Rating
    0
    troyg is on a distinguished road

      0  

    Default


    Thanks Colin and Brendan, much appreciated.

    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.

    Thanks
    Troy

  6. #6
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,717
    Vote Rating
    89
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    Draft mode is unlikely to make a huge difference, as the really slow part is IE's rendering and measuring, but it is worth turning off to find out. Another fun optimization (from https://developers.google.com/web-to...ompilerOptions) is -XdisableCastChecking, which will effectively remove casts (since JavaScript doesn't really do casts anyway) - as long as you don't rely on ClassCastException to make sure you didn't make a mistake, this is probably a safe argument to add. I've seen executable sizes drop by 5% or more, as well as performance improvements, though more in FF than IE.

  7. #7
    Sencha - GXT Dev Team BrendanC's Avatar
    Join Date
    Aug 2010
    Posts
    534
    Vote Rating
    3
    BrendanC is on a distinguished road

      0  

    Default


    John,
    I have also now added a far more efficient VML rendering of rectangle sprites without rounded corners. This completely gets rid of stop script pop ups for me loading your example code in IE 8.