CODEWITHSUNDEEP
javascriptperformance
mark
mark

Reputation: 62826

Understanding the report of Google Speed Tracer

I am trying to profile my YUI3 application using the Google Speed Tracer.

Here is the first snapshot:

enter image description here

So far so good, ST indicates a place taking 195ms. So, I zoom on it:

enter image description here

Even better, right? Here ST takes me to the offending line:

enter image description here

But what's next? I mean, here is the line:

return ('scrollTop' in node) ? node.scrollTop : Y.DOM.docScrollY(node);

And since the stack trace ends here I assume that node.scrollTop is returned, which is just a JS property access.

So what is the logic behind the claim that style recalculation took place at this point yielding 36ms execution time?

Can anyone explain it to me?

Upvotes: 0

Views: 427

Answers (1)

Joel Webber
Joel Webber

Reputation: 222

What is most likely occurring here is that you have accumulated changes to the DOM and/or stylesheets that require a style recalculation. But most rendering engines (definitely WebKit) defer style recalculation (as well as layout and rendering) as long as possible. In the best possible case, style recalculation, layout, and rendering all run in sequence once the current event handler returns control to native code.

But there are a number of things that can force an early recalculation or layout. The most common is that you access a property (e.g., scrollTop) on a DOM element that has to be computed. Other properties such as offset[Left Top Width Height] also commonly force a style recalculation and layout. The browser can't do this "in the background" because the rendering engine is (for the most part) single-threaded with the Javascript VM, so it typically has to wait for you to call into native code.

It's a bit hard to tell from your screenshots, but from what I can see it looks like you have a pretty big chunk of HTML being parsed right before this event (18ms worth), which could amount to a significant amount of style recalculation and layout (the latter of which takes 26ms just afterwards). I also see TableView._defRenderBodyFr() in your stack trace, which leads me to suspect that just before this getter was called, you have added/mutated a fair number of table rows. The TableView code most likely built up a big HTML string, but you only paid for the HTML parsing (and DOM construction) when it was set in innerHTML, but as soon as the code tried to access a property (in this case scrollTop) you paid for the style recalculation and layout.

You should be able to break these costs into smaller chunks (thus giving the UI thread a chance to breathe and generally feel more responsive) by reducing the number of rows affected by each mutation. I'm not a YUI expert, so I can't tell you how you would do it in their TableView, though.

Upvotes: 1

Related Questions