If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

TI: gzip benchmark slower with TI enabled

RESOLVED FIXED

Status

()

Core
JavaScript Engine
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: jandem, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

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.
(Reporter)

Updated

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

6 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.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.