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)
Created attachment 114239 [details] test case
*** Bug 70868 has been marked as a duplicate of this bug. ***
Created attachment 114241 [details] timeline of defer style-recalc
Created attachment 114242 [details] timeline of immediate style-recalc
Created attachment 114243 [details] initial patch for reference
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?
Johnny, what's the relationship between the 'initial patch for reference' in this bug and the last patch in bug 70868?
(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.
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.
(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.