[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