Closed
Bug 663087
Opened 13 years ago
Closed 11 years ago
TI: gzip benchmark slower with TI enabled
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
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.
Comment 1•13 years ago
|
||
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.
Reporter | ||
Comment 2•13 years ago
|
||
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•13 years ago
|
||
What does the fix from bug 663090 do for our score here?
Comment 4•11 years ago
|
||
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.
Description
•