Bug 103720

Summary: Keep ElementAttributeData sharing cache open for a while after document parsing finishes.
Product: WebKit Reporter: Andreas Kling <kling>
Component: DOMAssignee: Andreas Kling <kling>
Status: RESOLVED FIXED    
Severity: Normal CC: cmarcelo, gyuyoung.kim, koivisto, ojan, philn, rakuco, webkit-ews, webkit.review.bot, xan.lopez
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
koivisto: review+
Patch
webkit-ews: commit-queue-
Patch for landing none

Description Andreas Kling 2012-11-30 00:49:37 PST
We can gain additional sharing goodness from leaving the cache open for a bit, allowing HTML fragments inserted post-parse to use it.
Comment 1 Andreas Kling 2012-11-30 00:54:24 PST
Created attachment 176915 [details]
Patch
Comment 2 Antti Koivisto 2012-11-30 02:44:18 PST
Comment on attachment 176915 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=176915&action=review

> Source/WebCore/dom/DocumentParsingCaches.h:40
> +class DocumentParsingCaches {

I don't like the name but I'm lacking good suggestions.
Comment 3 Antti Koivisto 2012-11-30 03:24:25 PST
Comment on attachment 176915 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=176915&action=review

> Source/WebCore/dom/Document.cpp:4425
> +    static const int timeToKeepParsingCachesAliveAfterParsingFinishedInSeconds = 10;
> +    m_parsingCachesClearTimer.startOneShot(timeToKeepParsingCachesAliveAfterParsingFinishedInSeconds);

Could use a "why" comment here.
Comment 4 Andreas Kling 2012-11-30 17:44:00 PST
Created attachment 177066 [details]
Patch
Comment 5 Early Warning System Bot 2012-11-30 17:53:15 PST
Comment on attachment 177066 [details]
Patch

Attachment 177066 [details] did not pass qt-ews (qt):
Output: http://queues.webkit.org/results/15067359
Comment 6 Early Warning System Bot 2012-11-30 17:57:43 PST
Comment on attachment 177066 [details]
Patch

Attachment 177066 [details] did not pass qt-wk2-ews (qt):
Output: http://queues.webkit.org/results/15062604
Comment 7 EFL EWS Bot 2012-11-30 18:03:25 PST
Comment on attachment 177066 [details]
Patch

Attachment 177066 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/15054641
Comment 8 Andreas Kling 2012-11-30 18:17:16 PST
Created attachment 177074 [details]
Patch for landing

With my eyes open this time..
Comment 9 WebKit Review Bot 2012-12-02 04:04:39 PST
Comment on attachment 177074 [details]
Patch for landing

Clearing flags on attachment: 177074

Committed r136334: <http://trac.webkit.org/changeset/136334>
Comment 10 WebKit Review Bot 2012-12-02 04:04:48 PST
All reviewed patches have been landed.  Closing bug.
Comment 11 Ojan Vafai 2012-12-03 16:48:30 PST
I think this caused a ~12% improvement in dom_perf/CreateNodes.

Hard to tell. It could also be http://trac.webkit.org/changeset/136328/ maybe?

http://build.chromium.org/f/chromium/perf/linux-release-webkit-latest/dom_perf/report.html?graph=CreateNodes&trace=score&rev=170979&history=150
Comment 12 Andreas Kling 2012-12-03 16:51:13 PST
(In reply to comment #11)
> I think this caused a ~12% improvement in dom_perf/CreateNodes.
> 
> Hard to tell. It could also be http://trac.webkit.org/changeset/136328/ maybe?
> 
> http://build.chromium.org/f/chromium/perf/linux-release-webkit-latest/dom_perf/report.html?graph=CreateNodes&trace=score&rev=170979&history=150

Should be this one! Some of the CreateNodes subtests are using innerHTML to generate trees, which benefits from this change since they can now re-use the same ElementAttributeData. :)