Closed Bug 1572337 Opened 5 months ago Closed 2 months ago

Monitor event delays to allow modeling of input event latency at any point

Categories

(Core :: Performance, enhancement)

enhancement
Not set

Tracking

()

RESOLVED FIXED
mozilla72
Tracking Status
firefox72 --- fixed

People

(Reporter: jesup, Assigned: jesup, NeedInfo)

References

(Blocks 3 open bugs)

Details

(Whiteboard: [qf-])

Attachments

(7 files)

We want to be able to get a finer-grained view of jank by inferring what would be the delay of a hypothetical input event at any point in time. By monitoring the queue and run-start times of events in threads, we can reconstruct what delays an input event would see at any given point. See mozilla.dev.platform post "Measuring interactivity in a browser (especially during load)" 2019/7/31 Message-ID: <ybusgqlq3s5.fsf@jesup.org>

We want to be able to visualize these delays in the profiler (and replace the existing inject-events-every-16ms responsiveness code). We also would like to be able to collect this data (outside the profiler) during raptor runs, and maybe at other times (devtools?)

Whiteboard: [qf] → [qf-]

Hey there Randell. We're starting an effort to back-fill test coverage on all of our existing profiler features, in order to provide a more reliable product, especially as we're scaling up the users of the profiler. Would you mind adding a test to this new feature? I'd be happy to help point to some of our existing tests, and to review.

I know Gerald has been writing new unit tests for his new C++ machinery, but this feels like a good place to have a more integration style test.

For features that have different behaviors in the parent and content processes I've been using browser tests to ensure both pathways have coverage.

https://searchfox.org/mozilla-central/source/tools/profiler/tests/browser/browser_test_feature_jsallocations.js

For features that behave consistently no matter the process they are in, I've been using the faster xpcshell tests, e.g.

https://searchfox.org/mozilla-central/source/tools/profiler/tests/xpcshell/test_merged_stacks.js
https://searchfox.org/mozilla-central/source/tools/profiler/tests/xpcshell/test_feature_mainthreadio.js

Flags: needinfo?(rjesup)

Profile collected using this code to capture responsiveness: https://perfht.ml/2N8pV99

Flags: needinfo?(rjesup)
Attachment #9084858 - Attachment description: Bug 1572337: Test that we get non-0 responsiveness values in the profiler r=gerald → Bug 1572337: Test that we get non-0 responsiveness values in the profiler r=gregtatum

Threadpools run an event that then runs other events, so we need to tweak
things for GetRunningEventDelay()

Depends on D41279

Blocks: 1585327
Blocks: 1594015
Blocks: 1594566
Pushed by rjesup@wgate.com:
https://hg.mozilla.org/integration/autoland/rev/ea6d5b4b038b
Monitor running event delays and start times r=froydnj
Pushed by rjesup@wgate.com:
https://hg.mozilla.org/integration/autoland/rev/4eda65e054d8
ensure MainThread is registered with the profiler properly r=gerald
Pushed by rjesup@wgate.com:
https://hg.mozilla.org/integration/autoland/rev/00da7156d3fa
Make GetRunningEventDelay handle threadpools r=froydnj
Pushed by rjesup@wgate.com:
https://hg.mozilla.org/integration/autoland/rev/b3510afc9f79
replace Responsiveness measurement with Event delay measurements r=mstange
Pushed by rjesup@wgate.com:
https://hg.mozilla.org/integration/autoland/rev/913d6bd82284
Remove old responsiveness profiler measurement r=gerald
Pushed by rjesup@wgate.com:
https://hg.mozilla.org/integration/autoland/rev/fc8a37c2c22c
Test that we get non-0 responsiveness values in the profiler r=gregtatum

Backed out 3 changesets (bug 1572337, bug 1594015) for causing linting failures and build bustages

Follow up to the backout above.

Backout by aciure@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3334e244dd72
Backed out 3 changesets (bug 1572337, bug 1594015) for causing linting failures and build bustages CLOSED TREE
Attachment #9089219 - Attachment description: Bug 1572337: Remove old responsiveness profiler measurement r=mstange → Bug 1572337: Remove old responsiveness profiler measurement r=gerald
Regressions: 1594767

Avoids deadlocks on Windows

Depends on D41637

Pushed by rjesup@wgate.com:
https://hg.mozilla.org/integration/autoland/rev/3d2bf6bfe931
ensure MainThread is registered with the profiler properly r=gerald
https://hg.mozilla.org/integration/autoland/rev/1eedae351266
Monitor running event delays and start times r=froydnj
https://hg.mozilla.org/integration/autoland/rev/e25cefd5d1d1
Make GetRunningEventDelay handle threadpools r=froydnj
https://hg.mozilla.org/integration/autoland/rev/1167a0ab6288
replace Responsiveness measurement with Event delay measurements r=mstange
https://hg.mozilla.org/integration/autoland/rev/fef6230f3cb2
Remove old responsiveness profiler measurement r=gerald
https://hg.mozilla.org/integration/autoland/rev/2c97624e0f19
Test that we get non-0 responsiveness values in the profiler r=gregtatum
https://hg.mozilla.org/integration/autoland/rev/620c4222c7f3
Don't call TimeStamp::Now() within SuspendAndSample r=froydnj

== Change summary for alert #23812 (as of Mon, 11 Nov 2019 12:32:18 GMT) ==

Improvements:

11% perf_reftest_singletons external-string-pass.html macosx1014-64-shippable opt e10s stylo 1,138.65 -> 1,012.04

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

You need to log in before you can comment on or make changes to this bug.