[Webkit-unassigned] [Bug 119294] New: Remove a pointer from StringImpl

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Jul 30 16:31:15 PDT 2013


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

           Summary: Remove a pointer from StringImpl
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Keywords: BlinkMergeCandidate
          Severity: Normal
          Priority: P2
         Component: Web Template Framework
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: rniwa at webkit.org
                CC: darin at apple.com, ggaren at apple.com, koivisto at iki.fi,
                    barraclough at apple.com, akling at apple.com


Consider reducing the number of pointers in StringImpl as done in:
https://chromium.googlesource.com/chromium/blink/+/573a11ba5a27e49799cce332e7f5199c91578366

Remove a pointer from StringImpl

The m_buffer field is no longer needed. On 64 bit systems, this CL reduces the
sizeof(StringImpl) from 32 to 24 bytes.

The CL is a strict win, but I was curious how big an impact it has on actual
web sites so I looked at the STRING_STATS for the HTML Standard and ESPN.com.

== HTML Standard ==
Character data:                 798 kB (12065 strings)
StringImpl overhead (before):   386 kB (48% overhead)
StringImpl overhead (after):    290 kB (36% overhead)

== ESPN.com ==
Character data:               1,403 kB (10388 strings)
StringImpl overhead (before):   332 kB (24% overhead)
StringImpl overhead (after):    249 kB (18% overhead)

On these sites, StringImpl is a significant amount of overhead compared to the
total amount of character data actually stored in the strings. This CL saves
about 90 kB of memory and makes a noticeable dent in the total amount of memory
used by strings. Even after this CL, we're still spending a sizable amount of
memory on StringImpl overhead.

-- 
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