691174 - Investigate reducing calls to malloc() from nsStringBuffer.

Status: NEW

(Core :: XPCOM, defect)

Description

[Justin Lebar (not reading bugmail)]

My analysis from bug 688979 indicates that about 8% of mallocs in the browser are from strings:

109135 malloc's ( 4%):
  malloc at memory/jemalloc/jemalloc.c:6075
  nsStringBuffer::Alloc(unsigned long) at xpcom/string/src/nsSubstring.cpp:210
  nsAString_internal::MutatePrep(unsigned int, unsigned short**, unsigned int*) at xpcom/string/src/nsTSubstring.cpp:164
98183 malloc's ( 4%):
  malloc at memory/jemalloc/jemalloc.c:6075
  nsStringBuffer::Alloc(unsigned long) at xpcom/string/src/../../../../src/xpcom/string/src/nsSubstring.cpp:210
  nsACString_internal::MutatePrep(unsigned int, char**, unsigned int*) at xpcom/string/src/../../../../src/xpcom/string/src/nsTSubstring.cpp:164

(In this test run, I started up the browser, loaded gmail, nytimes, slashdot, and CNN, and then closed the browser.)

Using nsAutoTArray instead of nsTArray in the CSS engine resulted in a 2-3% RSS reduction (bug 681755 comment 31).  It's possible we'd see a similar improvement by using nsAuto{C,}String in place of ns{C,}String in a few key places.

Comment 1

[Benjamin Smedberg]

How does one gather the stats to know if there are stack strings which are easy wins?

Comment 2

[Justin Lebar (not reading bugmail)]

In theory, the analysis can use deeper backtraces, which would let us see where those strings are being allocated.  That, plus an indication of how long those allocations last, would help us find stack strings which are easy wins.

But for some reason it starts giving me funky backtraces around depth 6 or 7, which is how deep you need to go to break out of the string code.  Once I figure this out, I'll post more data in this bug.