Bug 103720 - Keep ElementAttributeData sharing cache open for a while after document parsing finishes.
Summary: Keep ElementAttributeData sharing cache open for a while after document parsi...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Andreas Kling
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-30 00:49 PST by Andreas Kling
Modified: 2012-12-03 16:51 PST (History)
9 users (show)

See Also:


Attachments
Patch (28.60 KB, patch)
2012-11-30 00:54 PST, Andreas Kling
koivisto: review+
Details | Formatted Diff | Diff
Patch (41.71 KB, patch)
2012-11-30 17:44 PST, Andreas Kling
webkit-ews: commit-queue-
Details | Formatted Diff | Diff
Patch for landing (24.85 KB, patch)
2012-11-30 18:17 PST, Andreas Kling
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
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. :)