199525 - Arena-allocate string objects in ns[C]StringArray

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect, P3)

Description

[Alec Flett]

I realized that we're doing some nasty stuff in nsStringArray:

PRBool 
nsStringArray::InsertStringAt(const nsAString& aString, PRInt32 aIndex)
{
  nsString* string = new nsString(aString);
  if (nsVoidArray::InsertElementAt(string, aIndex))
   ....
}

ack! new nsString!
this is nasty because it means we allocate both 16 bytes for an nsString, and
more for the string data itself! That's two allocations, and not cool.

we should keep an arena in nsStringArray, and arena-allocate the strings.
It shouldn't be too hard to keep a next-free system of arena management so that
we can reuse parts of the arena if a string gets nuked in the middle.

I'm going to do measurements to see how often this stuff is called, to see if it
is justified.

Another minor optimization we can do as a temporary solution is to allocate an
nsAutoString if the Length() is less than kDefaultStringSize.

Comment 1

[Alec Flett]

ok, I figured out the appropriate thresholds for nsAutoString vs. nsString, and
nsCAutoString vs. nsCString. The "sweet spot" for these strings are:
56 < length < 64 for PRUnichar strings
48 < length < 64 for char strings

this range is the length of string for which its actually advantageous to
allocate a single nsCAutoString or nsAutoString rather than an nsCString + a
buffer or nsString + a buffer. The reasoning being that the standard malloc
alignment and overhead mean that two small allocations are potentially bigger
than a single larger allocation. (and yes, I'm taking into account the null
terminator here)

I ran through the 30 urls on cowtools just to see what kind of strings get
created, of what lengths. On linux, what I found was that on a single run
through the 30 URLs, we only create about 4000 strings (total of char* and
PRUnichar* strings), and of those, about 3900 are less than the thresholds
describe above:

Count of String long: 36
Count of String medium: 9
Count of String short: 1175
Count of CString long: 0
Count of CString medium: 0
Count of CString short: 2719

(where "short" is less than the threshold, "medium" is in the sweet spot, and
"long" is longer than 64 characters)

so really there's no advantage to the last suggestion in this bug, given the
minor complexity that this addes to nsStringArray. I will focus on the arena
allocation instead.

though I also found this very interesting that we create so few nsStringArrays.
It makes me wonder if there is really much value in this bug at all.

Comment 2

[Darin Fisher]

hmm... interesting stuff.  keep in mind that we will probably be increasing our
usage of ns[C]StringArray over time.

Comment 3

[Doug Turner (:dougt)]

moving minimo bugs to the new bugzilla product.

Comment 4

[Aiko]

nsStringArray is obsolete, nobody should invest time optimizing APIs that are going away.