840809 - Shrink initial size of some per-compartment tables

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Nicholas Nethercote [inactive]]

We have lots of compartments:  150+ at start-up, and hundreds more in a session with lots of tabs.

Each compartment has several hash tables.  The default capacity of 32 is higher than necessary for some of these.  Just by changing the defaults we'll be able to save ~0.5 MB on start-up on a 64-bit build.

Comment 1

[Nicholas Nethercote [inactive]]

Attachment: (part 1) - Fix a comment and rename a constant in HashTable.h.

The default capacity of a js::HashTable is 32, not 16 as I thought.  I wonder
if it should be 16, which would match pldhash.

Comment 2

[Nicholas Nethercote [inactive]]

Attachment: (part 2) - Measure RegExpCompartment::inUse_.

Comment 3

[Nicholas Nethercote [inactive]]

Attachment: (part 3) - Shrink initial size of some per-compartment tables.

In this patch I made four of the tables initialize to the minimum size (which
is a capacity of 4).  I measured the improvements on Linux64 at start-up (with
~150 compartments present) and after running MemBench50 (~500 compartments
present).

* debuggees.  In normal execution all the tables are empty.  Changing to the
  minimum size table saves about 68 KiB at start-up and 217 KiB on MemBench50.

* RegExpCompartment::map_.  70--98% of them fit in the minimum size table.
  RegExpCompartment::inUse_. 97--98% of them fit in the minimum size table.
  Together that saves 201 KiB at start-up and 523 KiB on MemBench50.

* crossCompartmentWrappers.  

  - At start-up, 80% fit in the current default (cap=32).  After shrinking the
    start size:  39.2% fit in a capacity of 4; another 7% within a capacity of
    8, another 17% in a capacity of 16.  

  - In MemBench50, 80% fit in the current default (cap=32).  After shrinking,
    52% fit in 4, another 11% in 8, and another 16% in 16.

  This saves 143 KiB at start-up and 236 KiB on MemBench50.

Altogether, the savings are 412 KiB at start-up and 976 KiB on MemBench50.  Not
bad for a trivial patch.

Comment 4

[Nicholas Nethercote [inactive]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/dad25c17ccc7
https://hg.mozilla.org/integration/mozilla-inbound/rev/e3707e9cbba0
https://hg.mozilla.org/integration/mozilla-inbound/rev/b9cd1fa20502

Comment 5

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/dad25c17ccc7
https://hg.mozilla.org/mozilla-central/rev/e3707e9cbba0
https://hg.mozilla.org/mozilla-central/rev/b9cd1fa20502

Comment 6

[Jonathan Watt [:jwatt]]

For: http://hg.mozilla.org/mozilla-central/annotate/tip/content/svg/content/src/nsSVGFilters.cpp

Why is blame showing virtually every line as having last been touched by rev 121949, attributed to "(part 1) - Fix a comment and rename a constant in HashTable.h"?

Comment 7

[Nicholas Nethercote [inactive]]

> Why is blame showing virtually every line as having last been touched by rev
> 121949, attributed to "(part 1) - Fix a comment and rename a constant in
> HashTable.h"?

That's weird.  Each links in comment 4 and comment 5 each name nsSVGFilter.cpp as being modified by the patch, but don't show any diff.  And when doing |hg log -p| on the relevant revisions that file doesn't show up.

I certainly didn't do anything with that file.  Did it change name recently, or something like that?  Seems like an hg oddity, and one that's hard to do anything about now :/

Comment 8

[Jonathan Watt [:jwatt]]

The file has always had that name and been at that location.

I filed a bug over in Mercurial's bugzilla on this:

http://bz.selenic.com/show_bug.cgi?id=3833