592518 - setup "performance analysis" builds

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect, P5)

Description

[Andreas Gal :gal]

Please add a "performance analysis" nightly build to mozilla central. This should be an optimized build with a couple additional flags set. These builds will enable Xperf and dtrace performance analysis (at a slight overhead, which is why we don't want this in product/trunk builds).

Comment 1

[Andreas Gal :gal]

Builds should be available for every major platform (we already have "shark" builds, those we might want to roll over into this).

Comment 2

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Agal: 

Found in triage, sorry we missed this. 

1) is this still needed? (sorry we missed this first time).
2) what additional flags are needed?

(In reply to comment #1)
> Builds should be available for every major platform (we already have "shark"
> builds, those we might want to roll over into this).
3) Does this mean we no longer need shark builds like ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/firefox-7.0a1.en-US.mac-shark.dmg ?

Comment 3

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

summary of meeting with gal:

1) These "performance analysis" builds are basically a normal build, with a slightly different mozconfig. The instrumentation will allow developers to see timings during memory allocation/collection, etc, which is very useful for developers doing optimization work. 

2) sfink/gal will figure out the exact mozconfig changes and post a patch to this bug.

3) For now, these builds can be:
- only on mozilla-central
- only done nightly (not per checkin), and with no updates.
- only on linux
- no perf testing will be done on these builds. Unknown/unclear if we need to do unittests for these builds.

4) While this is nice to have, it is not super urgent.

Comment 4

[Steve Fink [:sfink] [:s:]]

I think this may need to start with a small set and expand later, when more options are implemented well enough to be worthwhile. Right now, I'd want these to be done across all platforms, because there are different things that make sense for Mac/Win/Linux. And mobile, because it probably has the most use for the instrumentation. 32bit vs 64bit probably doesn't matter yet, until someone is using them for something specific, so picking one or the other there should be fine for now. In the immediate future, the main benefit I see is preventing these options from breaking.

OSX:
  ac_add_options --enable-dtrace
  ac_add_options --enable-shark
  ac_add_options --enable-trace-jscalls
  ac_add_options --enable-functiontimer
  ac_add_options --enable-callgrind

Linux:
  ac_add_options --enable-trace-jscalls
  (--enable-dtrace once we get systemtap headers onto build boxes and bug 574403 lands)
  ac_add_options --enable-functiontimer
  ac_add_options --enable-callgrind

Win:
  ac_add_options --enable-ETW
  ac_add_options --enable-trace-jscalls
  ac_add_options --enable-functiontimer

I hope to have some JIT code registration to add to these soonish. And there are probably things I'm unaware of.

What and where are the files I should patch?

Unfortunately, I highly suspect that the build, or at least the tests, will fail with this constellation of parameters. Assigning this bug to myself until I can force it through try.

Comment 5

[Steve Fink [:sfink] [:s:]]

(In reply to comment #3)
> summary of meeting with gal:
> 
> 3) For now, these builds can be:
> - only on mozilla-central

yes

> - only done nightly (not per checkin), and with no updates.

yes

> - only on linux

No. All platforms. Definitely want debug symbols; not sure about --enable-optimize. Let's say "no" for now, since at the moment I'm saying we should use --enable-trace-jscalls and that'll throw things off anyway. But that means that these cannot replace the shark builds. I think we'll want to add some of these options (at least --enable-dtrace) to the shark build separately.

> - no perf testing will be done on these builds.

yes

> Unknown/unclear if we need to do unittests for these builds.

Yes! Need full unittests.

> 4) While this is nice to have, it is not super urgent.

yes

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

Android too! At least:

  ac_add_options --enable-trace-jscalls
  ac_add_options --enable-functiontimer

Comment 7

[Dietrich Ayala (:dietrich)]

(In reply to Mark Finkle (:mfinkle) from comment #6)
> Android too! At least:
> 
>   ac_add_options --enable-trace-jscalls
>   ac_add_options --enable-functiontimer

Is there a reason to not enable these two by default on Nightly? The overhead, if you don't set the env vars, is likely minimal. And enabling them by default would make it much easier for developers to consume the tools we're making for pinpointing non-performant code.

The MOZ_INSTRUMENT_EVENT_LOOP stuff was landed in this way.

Comment 8

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Dietrich Ayala (:dietrich) from comment #7)
> (In reply to Mark Finkle (:mfinkle) from comment #6)
> > Android too! At least:
> > 
> >   ac_add_options --enable-trace-jscalls
> >   ac_add_options --enable-functiontimer
> 
> Is there a reason to not enable these two by default on Nightly? The
> overhead, if you don't set the env vars, is likely minimal. And enabling
> them by default would make it much easier for developers to consume the
> tools we're making for pinpointing non-performant code.

We can certainly try to add them to the nightly. Talos will pick up any regressions from the overhead.

Comment 9

[David Teller [:Yoric] - still alive but not very active]

I am currently in the process of attepting to instrument code for xperf, so as to know which stage of execution we have reached. If this proves successful, I'll try and extend this to other performance suites.

Comment 10

[Steve Fink [:sfink] [:s:]]

(In reply to John O'Duinn [:joduinn] from comment #3)
> summary of meeting with gal:
> 
> 2) sfink/gal will figure out the exact mozconfig changes and post a patch to
> this bug.

Where is the mozconfig to patch?

Comment 11

[Steve Fink [:sfink] [:s:]]

I don't think this bug is serving any purpose. If we want something like this again in the future, we can use a new bug.