1124002 - Javascript performance 30x lower than in other browsers

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

[Ivan Kuckir]

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?

Comment 1

[:Gijs (he/him)]

Attachment: Compiled vs. uncompiled JS

Comment 2

[Jan de Mooij [:jandem]]

Attachment: 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.

Comment 3

[Jan de Mooij [:jandem]]

Attachment: Patch

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.

Comment 4

[Jan de Mooij [:jandem]]

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

Comment 5

[Jan de Mooij [:jandem]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/65aea1c559fd

Comment 6

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/65aea1c559fd

Comment 7

[Jan de Mooij [:jandem]]

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.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/399adb90c94d