See URL for the browser demo. For 1000 games: Chrome 13 : 840 ms Safari 5 : 932 ms Opera 11.11 : 987 ms Nightly 7 : 1343 ms
2 MB shell testcase due to the large word list.
The benchmark uses objects as sets/hashmaps and calls hasOwnProperty to check whether the set contains a word. Looking at the profile we spend about 17% under js::PropertyTable::search, another 17% under Atomize and 4% under js::PropertyTable::change.
Can you paste the Atomize profile? And how much slower are we?
Performance numbers for the browser are in comment 0. For the attached shell testcase: d8 : 774 ms jsc : 996 ms js -m : 1359 ms I just realized that the initialization (createWordHash) is also slow, so I added startProfiling/stopProfiling calls to measure only the benchmarking part. About 51% (!) is under hasOwnProperty. Under hasOwnProperty we have: --- Self Total --------------- 53.4% 53.4% js js::PropertyTable::search 0.0% 53.4% js js_LookupProperty 0.0% 53.4% js js_HasOwnPropertyHelper 34.0% 34.0% js Atomize 0.0% 33.8% js js_AtomizeString 0.0% 33.8% js js::ValueToId 0.0% 33.8% js js_HasOwnPropertyHelper 0.0% 0.1% js js::ValueToId 0.0% 0.1% js js_HasOwnPropertyHelper 6.0% 6.0% js js_LookupProperty 0.0% 6.0% js js_HasOwnPropertyHelper 2.9% 2.9% js js_HasOwnPropertyHelper 1.5% 1.5% js js_AtomizeString 0.0% 1.5% js js::ValueToId 0.0% 1.5% js js_HasOwnPropertyHelper ------ Can we optimize the atomization somehow?
Can you show the profile of Atomize?
Bug 611589 comment 2 has that profile already, right?
(In reply to comment #5) > Can you show the profile of Atomize? My Shark/Instruments shows almost nothing under Atomize: 95.6% 100.0% js Atomize 2.9% 4.4% js js_NewStringCopyN 0.9% 1.5% js js::gc::RefillFinalizableFreeList 0.7% 0.7% js PickChunk I don't know why, it's an --enable-profiling build but maybe it's inlining some functions? Does not explain why bz got a more interesting profile in bug 611589 though.
Things are almost certainly being inlined. That said, I can't recall what the profile in bug 611589 looked like, exactly. I might have done some manual lookup of the functions the per-line blame actually falls in... In this case, what I see is that in Atomize 1/3 of the time is a test instruction for the first isFree() test in jshashtable lookup(), another 1/6 is mov inside isFree() itself, 1/5 is the "key->length() != lookup.length" test in AtomStateEntry::match (on a shr instruction). Those seem to be the main hotspots. I would think that most of those are really L2 misses...
I just made a small test on my PC (specs here ==> http://pastebin.com/6j8as3XE) Mozilla Firefox latest nightly (12.0a1) 1.364ms 1.276ms 1.286ms 1.335ms 1.320ms Google Chrome Canary (18.0.1017.2) 1.562ms 1.259ms 1.230ms 1.315ms 1.476ms Opera Browser 11.61 913ms 800ms 839ms 835ms 803ms
On Win7, 1000 games: Nightly 26 - 694ms Chrome 29 - 801ms IE10 - 837ms Yay!
I got similar numbers. Awesome. Thanks for testing these old bugs Guilherme!
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.