662503 - Slower than other browsers on IE Wriggly Words benchmark

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Jan de Mooij [:jandem]]

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

Comment 1

[Jan de Mooij [:jandem]]

Attachment: Shell testcase

2 MB shell testcase due to the large word list.

Comment 2

[Jan de Mooij [:jandem]]

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

[Andreas Gal :gal]

Can you paste the Atomize profile? And how much slower are we?

Comment 4

[Jan de Mooij [:jandem]]

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

[Andreas Gal :gal]

Can you show the profile of Atomize?

Comment 6

[Boris Zbarsky [:bzbarsky]]

Bug 611589 comment 2 has that profile already, right?

Comment 7

[Jan de Mooij [:jandem]]

(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

[Boris Zbarsky [:bzbarsky]]

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...

Comment 9

[RNicoletto]

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

[Guilherme Lima]

On Win7, 1000 games:

Nightly 26 - 694ms
Chrome 29 - 801ms
IE10 - 837ms

Yay!

Comment 11

[Tom S. (please needinfo tschuster)]

I got similar numbers. Awesome. Thanks for testing these old bugs Guilherme!