Page 6 of 13 FirstFirst ... 45678 ... LastLast
Results 51 to 60 of 126

Thread: 4.x Framework performance Request for an Official Statement

  1. #51
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Location
    UK
    Posts
    3,791

    Default

    Interesting article. From comparing the removeCls methods in 4.0.7 to 4.1-pr1 it looks like className touching is one of the improvements being targeted.

  2. #52
    Sencha Premium Member
    Join Date
    Sep 2011
    Posts
    51

    Default

    @Gummy - No. I meant IE8: Version: 8.0.7601.17514
    No idea what the difference could be between our setups. I haven't had a chance to investigate fully. I did run a few times with Developer Tools open, and noticed the following error appeared several times:
    "Store defined with no model. You may have mistyped the model name."

    Interestingly, it takes roughly the same length of time (>40 seconds) to load the Sencha home page...
    http://www.sencha.com
    ...though several other websites I tried (cnn, jquery, drudgereport) load very quickly in IE8 (on the order of a second or two). Unfortunately, Dev Tools doesn't seem to provide a Net tab, so it's not immediately obvious what's taking all the time. Will post again if I learn something...

  3. #53
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Location
    UK
    Posts
    3,791

    Default

    You can ignore that error message in the docs app, it's an over-zealous warning.

    Unfortunately, Dev Tools doesn't seem to provide a Net tab, so it's not immediately obvious what's taking all the time.
    If you want to dig further...

    1. Try the docs app using a local copy of the docs.
    2. Use Fiddler to get a better sense of where time is being lost.
    3. Use DynaTrace if you're feeling really keen.


    I would guess this is a networking issue judging by what you've observed so far.

  4. #54
    Sencha Premium Member
    Join Date
    Sep 2011
    Posts
    51

    Default

    Try the docs app using a local copy of the docs.
    I first noticed the issue running this way. The time to load is over 40 seconds even when I serve from localhost.

    I would guess this is a networking issue judging by what you've observed so far.
    How could it be a network issue when the abnormally long load times are observed only in IE and only on the Sencha site?

  5. #55
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Location
    UK
    Posts
    3,791

    Default

    How could it be a network issue when the abnormally long load times are observed only in IE and only on the Sencha site?
    Actually, even running the docs on localhost isn't necessarily conclusive as it makes some requests to other domains.

    My theory goes a bit like this. Different browsers often have different networking settings, e.g. proxies. If a proxy has problems contacting a particular domain (all sorts of reasons that could happen) then it'll only affect the browser that's using the proxy.

    40s is long enough that it suggests you're hitting a timeout somewhere. It's possible other browsers are running up against the same timeout but they're handling it more gracefully. Try opening the docs in FF and see whether the Net tab shows anything time out after 40s.

  6. #56
    Sencha Premium Member
    Join Date
    Sep 2011
    Posts
    51

    Default

    Quote Originally Posted by skirtle View Post
    ...
    I did a bit of analysis comparing 3 & 4 in Chrome using MrSparks's example. It seems that the DOM contains fewer elements in 4, which can surely only be a good thing. However, the heap dump showed that 4 had huge numbers of arrays, strings and objects, far more than 3. Whether these actually affect performance is another matter but I do notice that a significant chunk of the initial load time is taken up by garbage collection. It doesn't account for the time difference in loading but it is suspicious.
    A week or so ago, I did a bit of digging into the way 4.1 was generating its markup. It appears that the generateMarkup method is called (in a highly recursive fashion) to generate an array representing a "tree" of html markup to be inserted in the dom. This array tends to be very large, because the html it contains is tokenized: e.g., it's not uncommon to see a sequence of elements such as...
    "<", "div", " ", "id", "=", ...

    In my particular application, a number of the trees so built contained over 1000 elements, with the largest I observed weighing in at between 6 and 7000 elements. After the array is fully built (through the use of templates and dynamically-compiled anonymous render functions), it is joined to produce the html markup string to be inserted in the dom. I'm guessing that all of this string/array manipulation comes at a cost, most likely a browser-dependent one...

    Don't know how much (if at all) it's used in 4.1 pr, but I did notice while using 4.x that IE was spending a lot of time in spliceSim, the non-native method used as a workaround for a known IE8 bug involving the native Array.splice. I doubt that has anything to do with the IE issues I'm seeing on the documentation site, however, as I didn't see that routine in the profile.

  7. #57
    Sencha Premium Member
    Join Date
    Sep 2011
    Posts
    51

    Default

    @skirtle - I'm starting to suspect the following "Embedded Open Type" file, which seems to spend a long time in the status bar during page load:
    use.typekit.com/k/uxj6dew-c-8007056-7081.eot?3bb2a6e53...<very long id string of some sort>

    As I understand it, Embedded Open Type fonts are a Microsoft creation, which perhaps explains why the Net traces in FF and Chrome don't show this file at all. Not sure what would prevent its loading properly/efficiently in my browser. There appear to be 2 additional files (js and css) pulled from that same domain, and IE is able to access both of them.

  8. #58
    Sencha Premium Member
    Join Date
    Sep 2011
    Posts
    51

    Default

    I've confirmed that an EOT (Embedded Open Type) font file served from use.typekit.com is what's causing the excessive load times for API docs in IE8. At skirtle's suggestion, I used Fiddler to inspect the traffic and saw that the request for uxj6dww-c-8007056-7081.eot was failing with a status of 504 (Gateway Timeout). According to the article referenced below, if the document contains a <script> tag prior to the @font-face referencing the eot file, page rendering is blocked until the eot file is completely loaded (or in this case, until it times out with error after 40+ seconds).

    http://www.stevesouders.com/blog/2009/10/13/font-face-and-performance/

    This certainly would explain the behavior I'm seeing. In light of the potential for issues, I'm wondering whether it might be best to remove the Sencha site's dependency on eot files altogether. Surely I'm not the only corporate user whose browser settings preclude his downloading this file. I'm thinking that the font data is stored in a data url in FF and Chrome. Perhaps a similar approach would work for IE? Or perhaps the eof file could be referenced before the first <script> tag to ensure that rendering isn't deferred...

  9. #59
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Location
    UK
    Posts
    3,791

    Default

    I suggest reporting the fonts issue here:

    http://www.sencha.com/forum/showthread.php?135036

  10. #60
    Sencha User dongryphon's Avatar
    Join Date
    Jul 2009
    Location
    Kansas
    Posts
    1,748

    Default

    Quote Originally Posted by skirtle View Post
    I have been wondering the same thing but I wouldn't dismiss the new class system quite yet, not until there's a concrete explanation for why it would cause performance problems. It may be to blame for some of the performance hit during initial load time but it's less clear how it could be to blame for UI snapiness during, for example, resize operations.
    Agreed. There may be cost at load time and we are looking into that. A deep(er) prototype chain might have run-time cost on old browsers, but it doesn't seem to be the critically hot performance areas.

    Quote Originally Posted by skirtle View Post
    I did a bit of analysis comparing 3 & 4 in Chrome using MrSparks's example. It seems that the DOM contains fewer elements in 4, which can surely only be a good thing. However, the heap dump showed that 4 had huge numbers of arrays, strings and objects, far more than 3. Whether these actually affect performance is another matter but I do notice that a significant chunk of the initial load time is taken up by garbage collection. It doesn't account for the time difference in loading but it is suspicious.
    The extra memory there is probably due to bulk rendering - we push string fragments into an array and join('') it to produce the render tree which we then write via innerHTML. When this was benchmarked against the non-bulk-rendering approach, it showed itself to be much faster even given the extra memory use.

    Of course we could be paying that back for the next bit while GC cleans up.
    Don Griffin

    "Use the source, Luke!"

Page 6 of 13 FirstFirst ... 45678 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •