Allow HashTables to have a capacity as small as four

RESOLVED FIXED in mozilla10

Status

()

Core
JavaScript Engine
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: njn, Assigned: njn)

Tracking

unspecified
mozilla10
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [MemShrink])

Attachments

(1 attachment)

(Assignee)

Description

6 years ago
Created attachment 570187 [details] [diff] [review]
patch

With the patch from bug 697931 applied, we see this distribution of KidsHash sizes:

30880 counts:
( 1)  12576 (40.7%, 40.7%): isHash: 2 / 16
( 2)   4704 (15.2%, 56.0%): isHash: 3 / 16
( 3)   2048 ( 6.6%, 62.6%): isHash: 1096 / 2048
( 4)   1680 ( 5.4%, 68.0%): isHash: 4 / 16
( 5)   1024 ( 3.3%, 71.3%): isHash: 455 / 1024
( 6)   1024 ( 3.3%, 74.7%): isHash: 480 / 1024
( 7)    752 ( 2.4%, 77.1%): isHash: 5 / 16
( 8)    512 ( 1.7%, 78.8%): isHash: 252 / 512
( 9)    512 ( 1.7%, 80.4%): isHash: 6 / 16

(where the data is of the form "isHash: count / capacity").  These numbers are weighted by capacities.

In other words, we have lots of KidsHashes with very few elements, and the current minimum HashTable size of 16 is excessive, esp. as KidsHashes grow rarely.

The attached patch, which luke r+'d via IRC, changes the minimum size from 16 to 4.  If you don't specify a size, however, the initial capacity still defaults to 16.  KidsHash already specifies a minimum size of 2, so this patch shrinks it without any explicit change.

With this patch applied, the "shape-kids" number for Gmail drops from ~300KB to ~185KB.
Attachment #570187 - Flags: review+
(Assignee)

Comment 1

6 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/d9b279e5adbe
https://hg.mozilla.org/mozilla-central/rev/d9b279e5adbe
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10

Comment 3

6 years ago
This patch seemed to have made a not-insignificant improvement in the Kraken benchmark on AWFY (64 bit.. 32 bit seems to be affected much less).  I wonder why?

On another note, is there a particular systemic reason that our JS performance on 32 bit is better than 64 bit?  The competition appears to have the opposite performance delta 32 vs 64.
(Assignee)

Comment 4

6 years ago
(In reply to Paul Wright from comment #3)
> This patch seemed to have made a not-insignificant improvement in the Kraken
> benchmark on AWFY (64 bit.. 32 bit seems to be affected much less).  I
> wonder why?

Huh.  It's entirely due to the improvement in gaussian-blur, AFAICT.  I did some profiling and couldn't see anything.  I suspect it's just noise, the patch saved some space but did nothing else and Kraken shouldn't really be affected since its compute-bound.

> On another note, is there a particular systemic reason that our JS
> performance on 32 bit is better than 64 bit?  The competition appears to
> have the opposite performance delta 32 vs 64.

The JITs have had more work done for 32-bit platforms, AIUI.
You need to log in before you can comment on or make changes to this bug.