663087 - TI: gzip benchmark slower with TI enabled

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jan de Mooij [:jandem]]

For the testcase in bug 663072 we have:

js -j   :  248 ms
js -m   :  319 ms
js -m -n:  379 ms
js      : 3912 ms
js -n   : 5012 ms

With -n -m there are 141 recompilations, with -n there's 12.8% under TypeMonitorResult.

Inlining fromCharCode should help -n -m a lot.

And we should figure out why we don't inline every charCodeAt call. Maybe the argument type is unknown or the string is a rope or something else.

Comment 1

[Brian Hackett [Laid off!]]

It looks like almost all of the work will be under Inflater, which is a big closure with lots of mutable state accessed by inner functions.  Don't know which js functions here are the hottest, but what I would assume are the core functions (e.g. zip_inflate_internal) are packed with accesses to these closure vars.  Filed bug 663138.

Comment 2

[Jan de Mooij [:jandem]]

Added this to awfy-assorted. I removed the largest file from the .tar.gz to get the array literal to a reasonable size. The difference between -m -n and -m is larger than in comment 0, not sure why.

d8         : 99 ms
js -j -m -p: 110 ms
js -j      : 123 ms
js -m      : 127 ms
js -m -n   : 225 ms

Comment 3

[Paul Wright]

What does the fix from bug 663090 do for our score here?

Comment 4

[Till Schneidereit [:till]]

I don't know how to make the test work in d8, but we're certainly much faster with TI than without, here.