Closed Bug 1124002 Opened 5 years ago Closed 5 years ago

Javascript performance 30x lower than in other browsers

Categories

(Core :: JavaScript Engine: JIT, defect)

35 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla38
Tracking Status
firefox37 --- fixed
firefox38 --- fixed

People

(Reporter: ivan.kuckir, Assigned: jandem)

References

Details

(Keywords: perf, reproducible, testcase)

Attachments

(3 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.99 Safari/537.36

Steps to reproduce:

I am creating a webapp for editing images. I "compile" my JS code before publishing with Closure Compiler (http://closure-compiler.appspot.com/home). "Compiled" code works as fast as original code in Chrome and IE 11, but it runs 30x slower in FF.

Here is a demo http://jsperf.com/pp-blending . Why is "f.blend.mainCnC" so slow in FF? Do you think you can make FF as fast as IE, or do you expect programmers to write special versions of code just for FF?
Component: Untriaged → JavaScript Engine
OS: Windows 7 → All
Product: Firefox → Core
Hardware: x86_64 → All
Attached file Shell testcase
Thanks for the report!

I can reproduce this in the shell with the attached testcase:

Original 326
Compiled: 8574

d8:

Original 243
Compiled: 256

I'll look into it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached patch PatchSplinter Review
The problem is that we have bad type information and think one of the operands of a MMul could be an object and we deoptimize. This in turns leads to bad type information for other Add/Mul/Sub/Div operations (their slow paths all show up in the profile).

This patch removes the unnecessary might-be-object and might-be-symbol checks, so that we will fall back to information from Baseline caches. This is fine because MToInt32 and MToDouble now properly set the Guard flag if the input could be a symbol or object.

With that I get:

Original: 332
Compiled: 210

So this fixes the problem and Compiled is now faster than Original even (and faster than d8). Still have to find out why Original is slower now.
Assignee: nobody → jdemooij
Status: NEW → ASSIGNED
Attachment #8552496 - Flags: review?(hv1989)
(In reply to Jan de Mooij [:jandem] from comment #3)
> Original: 332
> Compiled: 210
> 
> So this fixes the problem and Compiled is now faster than Original even (and
> faster than d8). Still have to find out why Original is slower now.

It seems to be a regalloc issue. With LSRA we have some really big move groups. If I use Backtracking I get:

Original: 221
Compiled: 218

So with BT, Compiled becomes a little slower but Original is way faster and both are faster than d8/Chrome. Hopefully BT will be enabled for all JIT code soon.
Depends on: 826741
Attachment #8552496 - Flags: review?(hv1989) → review+
Component: JavaScript Engine → JavaScript Engine: JIT
https://hg.mozilla.org/mozilla-central/rev/65aea1c559fd
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
Comment on attachment 8552496 [details] [diff] [review]
Patch

As we're still pretty early in the cycle, we should probably uplift this to 37 as the patch is just removing code and can make some operations a lot faster.

Approval Request Comment
[Feature/regressing bug #]: Older Ion issue.
[User impact if declined]: Websites/games a lot slower in some cases.
[Describe test coverage new/current, TreeHerder]: Tested on treeherder.
[Risks and why]: Low risk, the patch just removes some now-unnecessary checks.
[String/UUID change made/needed]: None.
Attachment #8552496 - Flags: approval-mozilla-aurora?
Attachment #8552496 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Depends on: 1140890
No longer depends on: 1140890
You need to log in before you can comment on or make changes to this bug.