Firefox is 2X slower than Chrome, Opera, and IE 9 one the Mega Man game at JSNES site

RESOLVED WORKSFORME

Status

()

defect
RESOLVED WORKSFORME
8 years ago
7 years ago

People

(Reporter: fehe, Unassigned)

Tracking

({perf})

Trunk
x86
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

8 years ago
Firefox is 2X slower than Chrome, Opera, and IE 9 on the Mega Man game at JSNES site.  Tested even with the JM builds, which include TI.

Doesn't matter what combination of JIT I choose, it remains slow.  With either default settings or JM only, I get about 33-38 FPS.  With TM only, it drops to about 4-5 FPS.  Chrome, Opera, and IE 9 are pretty steady at around 58 FPS.

The situation has been this way since the Firefox 4 betas.

STR:
1. Use any build of Firefox (release, nightly, TM, JM, or whatever)
2. Visit http://benfirshman.com/projects/jsnes/
3. Select Mega Man from the drop-down
4. Play the game and observe frame rate
5. Compare with the other major browsers

Platforms tested on (Firefox 32-bit):
- Intel Core i3 (non-sandy bridge) + Windows 7 64-bit
- AMD Athlon II X4 630 + Windows XP 32-bit
(Reporter)

Updated

8 years ago
Another test case for the profiler.
Blocks: WebJSPerf

Comment 2

8 years ago
I ran against a 32-bit Nightly, on Windows 7 64-bit system (Sandy Bridge) and got basically the same results (35ish FPS).

Running briefly through some of our tools, here's what I observed:

Hot Modules:
1. mozjs.dll (~43 %)
2. JIT       (~29 %)

Looking into mozjs, there was one part that stuck out, and it was in jsscope.cpp, in js::PropertyTable::search, line 229:

stored = *spp;

This load is missing cache quite often, coming out of LLC 80% of the time, and DRAM 9% of the time. This single load is costing 16% of the time spent in mozjs.dll.
UI, do you agree with Joe, to close?

Joe writes:
"I unfortunately no longer have the same Sandy Bridge machine I originally tested on last year, but did check on my Ivy Bridge machine with the same specs otherwise, and am seeing 58 FPS, instead of the 35ish FPS that had originally been reported. These two architectures aren't different enough to warrant that sort of difference, so it's pretty safe to say the problem has since been resolved.-Joe"
Whiteboard: [closeme 2012-08-20]
This is at 53fps for me. I also looked at this in JIT Inspector and there seems to be next to no performance fault. Except uses of this.bgbuffer[x] seem to always result in a stub call.
WFM per last two comments
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
Whiteboard: [closeme 2012-08-20]
(Reporter)

Comment 6

7 years ago
Sorry didn't see the comments, as I wasn't monitoring this bug for a while.

Anyways, it definitely is not resolved, as I still have the same system I originally tested this on and performance improved by only about 3 FPS since then.

Nevertheless, I doubt that this will get fixed (except maybe as a side effect), so I'm not going to reopen.
You need to log in before you can comment on or make changes to this bug.