2.4% winxp/8 e10s ts_paint regressions on inbound (v.46) on Jan 12 from rev: 592fc90e655a




JavaScript Engine
2 years ago
2 years ago


(Reporter: jmaher, Unassigned)


({perf, regression})

perf, regression
Dependency tree / graph

Firefox Tracking Flags



(Whiteboard: [talos_regression])

tracking-e10s: --- → -

Comment 1

2 years ago
looking back into this- I finally have a win8 build going for the missing revision.  A few pushes later there was bug 1240164 on the same test- that is why this looked suspicious.  I should have data by the end of the day.

Comment 2

2 years ago
well, I am unable to push to try and get a build with the revisions missing data, nor can I fill in on treeherder :(


2 years ago
Component: Talos → JavaScript Engine
Product: Testing → Core

Comment 3

2 years ago
I have ruled out bug 948267 with a try push (https://treeherder.mozilla.org/#/jobs?repo=try&revision=b9edbbd3e5c1&selectedJob=15894992), this leaves bug 1000780 as the culprit for this regression.  From reading the bug, it looks as though it is known there are other performance issues.

I know this is 2 weeks later- sort of hard to expect a quick fix, but I would like to confirm this is expected and document that along with any work done to fix this.
Blocks: 1000780
Flags: needinfo?(till)
Hmm, this isn't really expected, no. The test doesn't make use of Function#bind at all, AFAICT, and even if it did, it'd be highly unlikely to do so in a way that'd hit the perf cliffs mentioned in bug 1000780.

Joel, would it be possible to bisect this further? Specifically, testing with rccfd55971698 would be interesting, as the parts up to and including that one are preparatory and don't actually change Function#bind itself.

One possibility is that this is simply the time it takes to compile the added self-hosted JS. If that's the case, we can't immediately do anything about it. We do have plans to look into the startup costs associated with that, though, so medium-term, we should see improvements here. (If that really is the cause, that is.)
Flags: needinfo?(till) → needinfo?(jmaher)

Comment 6

2 years ago
odd, the builds are not working:

c:/builds/moz2_slave/try-w64-0000000000000000000000/build/src/dom/workers/WorkerPrivate.cpp(2213) : error C2614: 'mozilla::dom::workers::WorkerPrivateParent<mozilla::dom::workers::WorkerPrivate>' : illegal member initialization: 'mNowBaseTimeHighRes' is not a base or member
Return code: 1 

tips on how to fix this?  I don't see how it is related to the code changed- maybe I retrigger?
Flags: needinfo?(jmaher) → needinfo?(till)
Huh, that's certainly not related, no. A retrigger sounds good, yes.
Flags: needinfo?(till) → needinfo?(jmaher)

Comment 8

2 years ago
got it, I overlooked the obvious that there is a build breakage in the patch right before this set of patches landed, and was backed out right afterwards.  Did a new set of pushes:

for reference, here is the original commit:

lets give this ~2 hours for builds and results.
Flags: needinfo?(jmaher)
(In reply to Joel Maher (:jmaher) from comment #9)
> part 5 is the culprit:
> https://hg.mozilla.org/integration/mozilla-inbound/rev/f29f1d9a3cd3

In that case, I don't think there's much we can do immediately. Presumably, this only affects e10s because the content process is started only when a tab is loaded, so the parsing and bytecode compilation for the self-hosted JS is part of the measured time.

As I said before, we do have plans to tackle this, but they're not specific to this regression at all, so I'd argue we should live with this for now.

Comment 11

2 years ago
Thanks :till, lets mark this as wontfix and look for wins in the future!
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
Version: unspecified → Trunk
You need to log in before you can comment on or make changes to this bug.