Defer applying style recalculation when stylesheet is loaded to improve page load performance
https://bugs.webkit.org/show_bug.cgi?id=71886
Summary Defer applying style recalculation when stylesheet is loaded to improve page ...
Johnny(Jianning) Ding
Reported 2011-11-09 03:51:23 PST
Currently Webkit immediately does a force style recalculation after stylesheet is loaded, the style recalculation routine checks almost all nodes in the document at that time and may change/re-create render objects for all affected nodes. If there are several continuous style elements coming when there are already many nodes in the document, it can cost webkit much time to do several style recalculation cycles. Please check the attached test case. Comparing with WebKit, seems like other mainstream browsers (IE, Firefox, opera) all defer style recalculation. When running the attached test case on my machine. (Intel Xeon E5620 2.4G*2 processors, 12G memory), IE, firefox and Opera all use around 1 second, but Chrome and Safari use around 6 seconds. After looking Firefox source code, it shows firefox asynchronously apply style rules, please refer to the resource links in the end of this comment. Don't know how IE and opera did, but their loading speed does not look like doing immediate style recalc for each style element. I have a initial patch to change immediate style-recalc to scheduled style-recalc. I am still resolving the broken layout tests. (most of them should be rebaselined) Bug 70868 was created to handle part of this issue. Resource for firefox style load path (Last I checked) nsCSSStyleSheet::StyleSheetLoaded (http://mxr.mozilla.org/mozilla-central/source/layout/style/nsCSSStyleSheet.cpp#2046) mozAutoDocUpdate (http://mxr.mozilla.org/mozilla-central/source/content/base/src/mozAutoDocUpdate.h#51) nsDocument::BeginUpdate/EndUpdate (http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsDocument.cpp#3970) nsDocument::StyleRuleAdded (http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsDocument.cpp#4275) PresShell::BeginUpdate/EndUpdate (http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#2635) PresShell::StyleRuleAdded (http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#4433) nsIPresShell::ReconstructStyleDataInternal() (http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#4353) nsCSSFrameConstructor::PostRestyleEventCommon (http://mxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.cpp#11647)
Attachments
test case (846 bytes, text/html)
2011-11-09 03:51 PST, Johnny(Jianning) Ding
no flags
timeline of defer style-recalc (133.04 KB, image/png)
2011-11-09 03:59 PST, Johnny(Jianning) Ding
no flags
timeline of immediate style-recalc (149.51 KB, image/png)
2011-11-09 04:00 PST, Johnny(Jianning) Ding
no flags
initial patch for reference (3.63 KB, patch)
2011-11-09 04:02 PST, Johnny(Jianning) Ding
no flags
Johnny(Jianning) Ding
Comment 1 2011-11-09 03:51:48 PST
Created attachment 114239 [details] test case
Johnny(Jianning) Ding
Comment 2 2011-11-09 03:53:27 PST
*** Bug 70868 has been marked as a duplicate of this bug. ***
Johnny(Jianning) Ding
Comment 3 2011-11-09 03:59:30 PST
Created attachment 114241 [details] timeline of defer style-recalc
Johnny(Jianning) Ding
Comment 4 2011-11-09 04:00:00 PST
Created attachment 114242 [details] timeline of immediate style-recalc
Johnny(Jianning) Ding
Comment 5 2011-11-09 04:02:45 PST
Created attachment 114243 [details] initial patch for reference
Tony Gentilcore
Comment 6 2011-11-16 07:37:44 PST
Just curious what the state of this is. Are you looking for feedback on the initial patch here? Planning to turn it into a real patch?
Xianzhu Wang
Comment 7 2012-04-12 10:43:38 PDT
Johnny, what's the relationship between the 'initial patch for reference' in this bug and the last patch in bug 70868?
Johnny(Jianning) Ding
Comment 8 2012-04-24 09:38:40 PDT
(In reply to comment #7) > Johnny, what's the relationship between the 'initial patch for reference' in this bug and the last patch in bug 70868? last patch in bug 70868 is not relevant to this bug. I was thinking the load performance issue was caused by style created by script, but finally it turns out to be synchronous style calculation issue.
Eric Seidel (no email)
Comment 9 2013-01-15 16:38:32 PST
This bug came up in the context of http://en.wikipedia.org/wiki/Wikipedia load performance, which is abysmally slow (particularly on mobile), mostly due to repeated forced style recalcs from: https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=resources/mediawiki/mediawiki.js;hb=8ddc49d56345fdd74016424db37a6e187829948b#l445 I have not yet tried your patch to see how it changes load performance, but I'm curious to do so.
Johnny(Jianning) Ding
Comment 10 2013-01-15 17:14:10 PST
(In reply to comment #9) > This bug came up in the context of http://en.wikipedia.org/wiki/Wikipedia load performance, which is abysmally slow (particularly on mobile), mostly due to repeated forced style recalcs from: > https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=resources/mediawiki/mediawiki.js;hb=8ddc49d56345fdd74016424db37a6e187829948b#l445 > > I have not yet tried your patch to see how it changes load performance, but I'm curious to do so. I haven't touched this bug for quite a while. However I believe the direction of the initial patch is right and Firefox does asynchronously apply style rules (at least last time I dug into gecko source). Hopefully I can find some time to get back to this.
Note You need to log in before you can comment on or make changes to this bug.