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?
Keywords: perf, reproducible, testcase
OS: Windows 7 → All
Product: Firefox → Core
Hardware: x86_64 → All
Created attachment 8552422 [details] 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
Created attachment 8552496 [details] [diff] [review] 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.
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+
Status: ASSIGNED → RESOLVED
Last Resolved: 4 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?
status-firefox37: --- → affected
status-firefox38: --- → fixed
Attachment #8552496 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
status-firefox37: affected → fixed
You need to log in before you can comment on or make changes to this bug.