[Webkit-unassigned] [Bug 59449] New: Investigate template bloat in HashTable

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Apr 26 05:30:28 PDT 2011


https://bugs.webkit.org/show_bug.cgi?id=59449

           Summary: Investigate template bloat in HashTable
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Web Template Framework
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: tonyg at chromium.org
                CC: satish at chromium.org


A treemap of the chromium binary size by compilation unit is available here: http://neugierig.org/software/chromium/bloat/

Zoom in on WebKit, then JavaScriptCore, then wtf. Notice that all of wtf is 520k and of that ~70% (370k) is HashTable+HashMap+related classes. It looks to me like the template structure is forcing the entire class to be recompiled for every combination of key/value type used (and it is used quite a bit in WebCore). Obviously this is a very performance sensitive class, but maybe there are some ways to preserve the perf and still cut down on some space.

Some ideas:
- Hoist out parts of the implementation that aren't type dependent into a base class (although they look scarce). This was very successful for RefPtr in http://trac.webkit.org/changeset/36663.
- Specialize a version for pointers so that they can all share one, instead of having a different one for each pointer.
- There are 4 nearly identical lookup* implementations. They were expanded in http://trac.webkit.org/changeset/27176 for a perf improvement, but perhaps there is an alternative to keep the perf without so much space.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list