If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

TM: Dromaeo v3 Sunspider massive slowdown after 2-28 merge

RESOLVED INCOMPLETE

Status

()

Core
JavaScript Engine
P2
major
RESOLVED INCOMPLETE
9 years ago
7 years ago

People

(Reporter: RyanVM, Unassigned)

Tracking

({perf, regression})

Trunk
x86
Windows Vista
perf, regression
Points:
---
Bug Flags:
blocking1.9.1 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

9 years ago
See the URL above. This regressed on m-c with the Sat Feb 28 11:57:55 2009 -0800 TM merge. It regressed in the TM nightlies between 2-26 and 2-27.

Regression range:
http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=aea34f524423&tochange=737ca70d654f
(Reporter)

Updated

9 years ago
Flags: blocking1.9.1?
Keywords: perf, regression
Summary: Dromaeo v3 Sunspider massive slowdown after 2-28 TM merge → TM: Dromaeo v3 Sunspider massive slowdown after 2-28 merge
(Reporter)

Comment 1

9 years ago
Today's TM merge didn't help this, FWIW.
(Reporter)

Comment 2

9 years ago
http://dromaeo.com/?id=61342,61343,61567

First two are the same as the URL from the bug. Third is today's build. It looks like some of the tests are back to where they were, but some are still in bad shape.
(Reporter)

Comment 3

9 years ago
It appears that whatever caused this regression is fixed on the Tracemonkey branch. The link below shows the following TM nightlies: 2-26, 3-3, 3-4, 3-5, and 3-6
http://dromaeo.com/?id=61794,61788,61786,61791,61792

The 2-26 build shows the numbers I got with the final TM nightly before the regression hit. The 3-3 build shows the regression fully. The 3-4 and 3-5 builds show some improvement in the tests, such as AES. The 3-6 shows us fully returning to pre-regression performance levels and then some.

I'll confirm that this is fixed when the next TM merge occurs, but this certainly looks promising.

Comment 4

9 years ago
Is bug 480494 related to this? 

It does have an earlier regression range though, http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=4ada519b5c97&tochange=5de9f1e51c68
(Reporter)

Comment 5

9 years ago
http://dromaeo.com/?id=61342,61928

The first is the original final pre-regression build from comment #0. The second is current tip after today's m-c merge. As you can see, things are looking very good, except for the two DNA tests. The rest look to be even or faster with today's build, and the final score is higher with today's build.

So, it looks like this is mostly fixed, but not all the way yet.

Updated

9 years ago
Flags: blocking1.9.1? → blocking1.9.1+
(Reporter)

Comment 6

9 years ago
http://dromaeo.com/?id=61342,62632

Pre-regression build and m-c tip including today's m-c merge. DNA is clearly still showing problems, but everything else looks good (or close enough to be considered equal)

Updated

9 years ago
Priority: -- → P2
(Reporter)

Comment 7

9 years ago
http://dromaeo.com/?id=61342,62632,63738

Running a build off the current tip (post upvar2 landing), overall speed is definitely up. However, that mainly seems to be due to a massive speedup of Bitwise And. Otherwise, some of the other tests (like Compute Bits in Byte) are showing regressions.
upvar2 had nothing to do with any change to bitops-3bit-bits-in-byte.js (if that is the "Compute Bits in Byte" test) since that test has two top-level functions, no closures. Either some other patch made for a change, or this is noise (which could be a bug in itself).

Dromaeo is not always measuring what the individual SunSpider tests were intended to measure, and do measure when run via SunSpider. See bug 480494 comment 24.

/be
(Reporter)

Comment 9

9 years ago
Yeah, it could very well have been another one of the changes from the TM merges that happened over the last 48 hours or so. I doubt a change of an order of magnitude is noise, though, especially given that the numbers have been otherwise stable on that test to this point.
If DNA is the main issue, I'm already working on that in bug 480494.
Depends on: 480494

Comment 11

9 years ago
It's more likely to be Andreas' type mismatch patch that improved this.
Who owns this?
I intend to work on this, but I have 4.5 blockers ahead of it in my queue, so I didn't want to take it until I cleared those out.

Comment 14

9 years ago
given these results, I don't think we can block on this:

http://dromaeo.com/?id=65550,65551
Flags: blocking1.9.1+ → blocking1.9.1-
(In reply to comment #14)
> given these results, I don't think we can block on this:
> 
> http://dromaeo.com/?id=65550,65551

What versions are being compared in that view?

Comment 16

9 years ago
Fx3 (the slower one) vs. Fx3.5
We're not going back to this one any time soon, I have confidence.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.