Closed
Bug 662503
Opened 13 years ago
Closed 11 years ago
Slower than other browsers on IE Wriggly Words benchmark
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: jandem, Unassigned)
References
(Blocks 2 open bugs, )
Details
(Keywords: perf, Whiteboard: ietestdrive)
Attachments
(1 file)
499.73 KB,
application/zip
|
Details |
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
Reporter | ||
Comment 1•13 years ago
|
||
2 MB shell testcase due to the large word list.
Reporter | ||
Comment 2•13 years ago
|
||
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.
Comment 3•13 years ago
|
||
Can you paste the Atomize profile? And how much slower are we?
Reporter | ||
Comment 4•13 years ago
|
||
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?
Comment 5•13 years ago
|
||
Can you show the profile of Atomize?
Comment 6•13 years ago
|
||
Bug 611589 comment 2 has that profile already, right?
Reporter | ||
Comment 7•13 years ago
|
||
(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.
Comment 8•13 years ago
|
||
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...
Updated•13 years ago
|
Whiteboard: ietestdrive
Comment 9•12 years ago
|
||
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
Comment 10•11 years ago
|
||
On Win7, 1000 games: Nightly 26 - 694ms Chrome 29 - 801ms IE10 - 837ms Yay!
Comment 11•11 years ago
|
||
I got similar numbers. Awesome. Thanks for testing these old bugs Guilherme!
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Updated•11 years ago
|
Blocks: ietestdrive
You need to log in
before you can comment on or make changes to this bug.
Description
•