TI: gzip benchmark slower with TI enabled




8 years ago
6 years ago


(Reporter: jandem, Unassigned)


(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)


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.
Depends on: 663090
Depends on: 663138
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.
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

7 years ago
What does the fix from bug 663090 do for our score here?
I don't know how to make the test work in d8, but we're certainly much faster with TI than without, here.
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.