Closed Bug 594249 Opened 14 years ago Closed 6 years ago

JägerMonkey regression has slowed down significantly in past week.

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE
Tracking Status
blocking2.0 --- -

People

(Reporter: bugs, Unassigned)

References

()

Details

(Whiteboard: [softblocker] [needs review billm])

Attachments

(1 file)

http://js1k.com/demo/639

If I open this demo, set depth to 30, size to 512, leave others at default, and wait, it takes ~70 seconds to complete the initial processing in M-C.  To do a complete loop of the zoom takes ~65 seconds.

Last week's JägerMonkey (regretably I had not noted down the build, was most likely from Friday and before the TraceMonkey merge) took ~80 seconds to complete the initial processing, and did a complete loop in about ~60 seconds.

By comparison, Google Chrome 7 was basically unusable, alerting for slow scripts repeatedly, and took ~80 seconds just to get to 23 (that's where I halted it).

*THIS* week's JägerMonkey is comparable to GC7 in behaviour.  If I turn on tracing only, it is significantly slower than last week's, but functional.  If I turn on method jit only, it is about as slow as GC7, maybe a bit less.  If I turn on both, it seems about the same as if it is on method jit only.

dmandelin suggested it might have been due to some tuning of the tracing/method integration he had done recently.
BTW, waited 'till I got home and to a computer w/ javascript so I could file in Core/Firefox despite the buggy template. *bows*
Actually, both on is slower than method jit only (working from memory of earlier here) - quite a bit slower than GC7.
blocking2.0: --- → ?
Two things here. First, the tracejit does really well on this code and beats the methodjit handily. Chrome is also slow here, so this isn't terribly surprising.

The methodjit+tracejit combo runs slowly because of the MIN_LOOP_ITERS change (changeset 5d10c2119565). When I set MIN_LOOP_ITERS to 0, the test runs just as fast as with tracejit alone.
blocking2.0: ? → betaN+
Depends on: 580468
We're spending all our time in the interpreter, it looks like there is no recorder, interpMode=RECORD, and leaveOnSafePoint is false. So that's a bug. It's possible there will be a second bug where we need to tune the tracer. If so, that'll be a follow-up.
Assignee: general → dvander
Status: NEW → ASSIGNED
With this we don't spend all our time in the interpreter, but the test still takes about 6 minutes to run - faster than Chrome, but Bill's interested in seeing if we can do better by staying on trace.
Attachment #494149 - Flags: review?(wmccloskey)
Assignee: dvander → wmccloskey
billm: review ping!  dvander put the patch up 24 days ago.
I'm not sure what to do here. I can't reproduce the problem dvander encountered, even in a build from 11-29. When I run the benchmark with the profiler, we spend 98.5% of the time on trace. We're also about 3.5x faster than Chrome.

I think it's best to wait until dvander gets back. It may be a Mac-specific problem.
Whiteboard: softblocker
Whiteboard: softblocker → [softblocker] [needs review billm]
** PRODUCT DRIVERS PLEASE NOTE **

This bug is one of 19 being moved from blocking2.0:betaN+ to blocking2.0:- as we reached the endgame of Firefox 4. The rationale for the move is:

 - the bug had been identified as a "soft" blocker which could be fixed in some follow up release
 - the bug had been identified as one requiring beta coverage, thus is not appropriate for a ".x" stability & security release

The owner of the bug may wish to renominate for .x consideration.
blocking2.0: betaN+ → .x+
(er updating flag to "-" as per previous comment!)
blocking2.0: .x+ → -
On my about-to-be-FF4 Windows nightly, we get destroyed by that demo (i7, one core is pegged).  Browser is unusable until one of my ctrl-Ws gets through.
Assignee: wmccloskey → general
Seems to run reasonably well with JM+TI on a recent nightly.
Assignee: general → nobody
No assignee, updating the status.
Status: ASSIGNED → NEW
No assignee, updating the status.
No assignee, updating the status.
No assignee, updating the status.
No assignee, updating the status.
JaegerMonkey is long gone.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: