Closed Bug 663087 Opened 13 years ago Closed 11 years ago

TI: gzip benchmark slower with TI enabled

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: jandem, Unassigned)

References

(Blocks 1 open bug)

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.
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
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
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.