Slower than other browsers on IE Wriggly Words benchmark

RESOLVED WORKSFORME

Status

()

defect
RESOLVED WORKSFORME
8 years ago
6 years ago

People

(Reporter: jandem, Unassigned)

Tracking

(Blocks 2 bugs, {perf})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: ietestdrive, )

Attachments

(1 attachment)

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
Posted file Shell testcase
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?
(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...
Whiteboard: ietestdrive
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
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.