Closed Bug 1624987 Opened 4 years ago Closed 4 years ago

Too much webaudio data in PGO profiles

Categories

(Firefox Build System :: Toolchains, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: away, Assigned: padenot)

References

(Regression)

Details

(Keywords: perf-alert, regression, Whiteboard: [no-nag] )

Attachments

(1 file)

The top 4 functions in our profiles are from speex. I'm concerned that this might be making other functions look less important by inflating the "max count". Does the webaudio test have any settings that we can put on the query string to request fewer iterations during PGO training?

$ llvm-profdata.exe show --topn=10 webaudio-cross-profdata/merged.profdata
Instrumentation level: IR
Total functions: 373333
Maximum function count: 435488822
Maximum internal block count: 438141302
Top 10 functions with the largest internal block counts:
  /builds/worker/checkouts/gecko/media/libspeex_resampler/src/resample.c:resampler_basic_direct_single, max count = 438141302
  moz_speex_inner_product_single, max count = 435488822
  moz_speex_have_single_simd, max count = 434745518
  moz_speex_resampler_process_float, max count = 413347481
  ?IsHTMLWhitespace@nsContentUtils@@SA_N_S@Z, max count = 296315761
  ??$AssignJSString@U?$FakeString@_S@binding_detail@dom@mozilla@@$0A@@@YA_NPAUJSContext@@AAU?$FakeString@_S@binding_detail@dom@mozilla@@PAVJSString@@@Z, max count = 254616496
  ?ValueIncludes@nsStyleUtil@@SA_NABV?$nsTSubstring@_S@@0ABV?$nsTStringComparator@_S@@@Z, max count = 239501400
  ?Equals@?$nsTStringRepr@_S@detail@mozilla@@QBI_NABV123@@Z, max count = 221591145
  ?s_HashKey@?$nsTHashtable@V?$nsBaseHashtableET@VnsStringHashKey@@V?$RefPtr@VStyleSheet@mozilla@@@@@@@@KAIPBX@Z, max count = 213004820
  ?append@StringBuffer@js@@QAE_NPAVJSLinearString@@@Z, max count = 192568649

The resampler is not only used for Web Audio, it's used for a very big portion of all audio playback, especially on Windows. As such, I think it's really quite important.

I can certainly add something to reduce the number however, we're upstream on this.

Actually I don't know where I should make the patch, what copy of https://github.com/padenot/webaudio-benchmark/ are you using for this?

Flags: needinfo?(dmajor)

As of https://github.com/padenot/webaudio-benchmark/commit/9429cda0cc01538d1e3b11e721c003a79f5a5216, this is possible, ?duration=x allows choosing the benchmark duration in seconds, 120 is the default.

(In reply to Paul Adenot (:padenot) from comment #2)

Actually I don't know where I should make the patch, what copy of https://github.com/padenot/webaudio-benchmark/ are you using for this?

The PGO training uses the same file as Raptor, at https://searchfox.org/mozilla-central/source/third_party/webkit/PerformanceTests/webaudio. (Hm, I didn't realize the origin of these files was your github, I wonder why we store them under third_party/webkit.)

Flags: needinfo?(dmajor)

Unclear what the procedure to update this is... I can do it manually if that's ok.

I'm not entirely clear on the procedure either. There is an update.sh but it looks suspiciously simple, I have a feeling it will stomp over the local changes like the if (location.search == '?raptor') { block.

You're right. I'm going to resync everything upstream, and then we'll do the update.sh thing.

Assignee: nobody → padenot
Pushed by padenot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6055f2b2da44
Update webaudio-benchmark. r=dminor
Backout by shindli@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/257526acf9a8
Backed out changeset 6055f2b2da44 for raptor-webaudio-firefox raptor failures CLOSED TREE

Weird. I'll try locally, the log is not very useful.

Flags: needinfo?(padenot)

The improvement:
== Change summary for alert #25500 (as of Fri, 27 Mar 2020 04:38:05 GMT) ==

Improvements:

0.31% installer size osx-shippable opt nightly 82,116,844.83 -> 81,859,187.67

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=25500

And the backout:
== Change summary for alert #25495 (as of Thu, 26 Mar 2020 17:40:08 GMT) ==

Regressions:

0.39% installer size osx-shippable opt nightly 81,840,608.58 -> 82,157,255.67

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=25495

Pushed by padenot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/efa017cf034f
Update webaudio-benchmark. r=dminor

You can retry now, ?duration=x make the test generate x seconds of audio. The default is now aligned to 120 (was variable before).

Flags: needinfo?(dmajor)
Keywords: leave-open
Regressions: 1625912
Regressions: 1625980

David, can we close this now? We can adjust, these days, I don't know how much we've explored the new parameter space.

Yes, I took one more look at recent profiles and I'm happy with where we're at.

Thanks a lot for your patience with this, Paul. I think it ended up being a lot hairier than either of us expected or wanted.

Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(dmajor)
Resolution: --- → FIXED
Keywords: leave-open
Keywords: regression
Whiteboard: [no-nag]
Depends on: 1630661
Has Regression Range: --- → yes
Keywords: regression
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: