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, URL)

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
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

8 years ago
Posted file Shell testcase
2 MB shell testcase due to the large word list.
(Reporter)

Comment 2

8 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

8 years ago
Can you paste the Atomize profile? And how much slower are we?
(Reporter)

Comment 4

8 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

8 years ago
Can you show the profile of Atomize?
Bug 611589 comment 2 has that profile already, right?
(Reporter)

Comment 7

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

8 years ago
Whiteboard: ietestdrive

Comment 9

7 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

6 years ago
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.