Closed
Bug 533584
Opened 15 years ago
Closed 6 years ago
Improve PROPERTY_CACHE_HASH to reduce collisions, raise cache hit rate
Categories
(Core :: JavaScript Engine, defect, P3)
Core
JavaScript Engine
Tracking
()
RESOLVED
INVALID
mozilla1.9.3a1
People
(Reporter: brendan, Assigned: jorendorff)
Details
Regarding bug 533254 and its testcase, which has some apparent deadwood that turns out to be required to reproduce the assertbotch without that bug's patch: [3:59pm] brendan: indeed, property cache collisions [3:59pm] jorendorff: yep, got your message <brendan> yes, propcache.stats differs -- yuck [4:00pm] brendan: http://pastebin.mozilla.org/689381 [4:00pm] brendan: full analysis [4:00pm] brendan: the ^ hurts in PROPERTY_CACHE_HASH [4:00pm] brendan: could use + to avoid "binary subtraction" effect [4:00pm] brendan: the intermediates i dumped in gdb nicely differ by the additive inverse of the shape delta (shapes go up, kpc intermediate hash goes down, by 2) [4:01pm] brendan: stupid xor! [4:01pm] jorendorff: amazing! hang on [4:09pm] jorendorff: sorry, had to check the bitmath to believe it; i've never seen it happen before [4:10pm] jorendorff: well any significant improvement in hit rate has to be more important than the difference between a xor instruction and an add [4:11pm] jorendorff: the thing is, at least the current approach shuffles the bits [4:11pm] jorendorff: if we add instead, we might end up having some idiom that triggers worst-case behavior. [4:12pm] brendan: yes, it may be we just want the low pc bits [4:12pm] brendan: for these setprop/initprop strides along the cache, anyway [4:14pm] jorendorff: ok, i think i would try + first... wow Measure twice, cut once... filing this to remind myself to see what can be done. Feel free to steal this bug. /be
Reporter | ||
Comment 1•15 years ago
|
||
Jason kindly agreed to take ownership of this bug. /be
Assignee: brendan → jorendorff
Reporter | ||
Comment 2•15 years ago
|
||
I would be happy with /tmp/propcache.stats wins for SunSpider tests, maybe v8, and no perf regression according to our infrastructure. More exhaustive testing would be gravy; not sure how to get it though. Instrument the cache keys probed for in a real Firefox multi-tab session and play them back with old and new algs? /be
Comment 3•6 years ago
|
||
Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
Comment 4•6 years ago
|
||
Property cache was removed 5+ years ago.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•