Closed Bug 1345540 Opened 9 years ago Closed 8 years ago

Measure input event handler to paint request latency

Categories

(Toolkit :: Performance Monitoring, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla55
Performance Impact high
Tracking Status
firefox55 --- fixed

People

(Reporter: wcpan, Assigned: wcpan)

References

Details

Attachments

(1 file)

In bug 1313465, we want to measure event to dispatch latency, which can be divide to three parts: 1. from user input to event dispatcher (including IPC) 2. from event dispatcher to paint request (mostly in JavaScript engine) 3. from paint request to actual rendering (compositor, gfx ... etc.) This bug measures the second part.
Assignee: nobody → wpan
Blocks: 1313465
Whiteboard: [qf:p1]
Comment on attachment 8859980 [details] Bug 1345540 - Measure input event handling latency. , data-review?bsmedberg https://reviewboard.mozilla.org/r/132026/#review134816 ::: toolkit/components/telemetry/Histograms.json:11407 (Diff revision 2) > + "expires_in_version": "60", > + "kind": "exponential", > + "high": 5000, > + "n_buckets": 100, > + "bug_numbers": [1345540], > + "description": "Time (ms) for the mouse click event spent in handlers." This isn't quite right, since the events are mousedown/up. recording mouseup would include click, but mousedown certainly isn't including click Perhaps we need to tweak INPUT_EVENT_QUEUED_CLICK_MS too a bit.
Attachment #8859980 - Flags: review?(bugs) → review-
And this isn't about part (2). Perhaps _CLICK_ should be split to MOUSEDOWN and MOUSEUP
Comment on attachment 8859980 [details] Bug 1345540 - Measure input event handling latency. , data-review?bsmedberg https://reviewboard.mozilla.org/r/132026/#review135674 I mostly don't understand why this is so different to the previous version of the patch. Keeping all the measurements in presshell wouldn't affect microbenchmarks at least. ::: dom/events/EventListenerManager.cpp:74 (Diff revision 3) > (mIsMainThreadELM && ls->mTypeAtom == userType) || \ > (!mIsMainThreadELM && ls->mTypeString.Equals(typeString)))) || \ > (allEvents && ls->mAllEvents)) > > + > +class AutoAccumulateHandlerTime { { goes to its own line with class definitions. ::: dom/events/EventListenerManager.cpp:1156 (Diff revision 3) > result = CompileEventHandlerInternal(aListener, nullptr, nullptr); > aListener = nullptr; > } > > if (NS_SUCCEEDED(result)) { > + AutoAccumulateHandlerTime timer(aDOMEvent); We definitely don't want this here. This would most probably start to show up in microbenchmarks: addref/release event for each listener call and also calling Now()
Attachment #8859980 - Flags: review?(bugs) → review-
Comment on attachment 8859980 [details] Bug 1345540 - Measure input event handling latency. , data-review?bsmedberg https://reviewboard.mozilla.org/r/132026/#review136212
Attachment #8859980 - Flags: review?(bugs) → review+
Comment on attachment 8859980 [details] Bug 1345540 - Measure input event handling latency. , data-review?bsmedberg Request data review.
Attachment #8859980 - Flags: feedback?(benjamin)
Comment on attachment 8859980 [details] Bug 1345540 - Measure input event handling latency. , data-review?bsmedberg https://reviewboard.mozilla.org/r/132026/#review138062 data-r=me
Attachment #8859980 - Flags: review+
Attachment #8859980 - Flags: feedback?(benjamin)
seems to have 3 open issues in mozreview that need to be fixed first before we can use autoland
Flags: needinfo?(wpan)
Keywords: checkin-needed
Ah, I forgot about that, fixed now.
Flags: needinfo?(wpan)
Pushed by cbook@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e9a2a51f1c14 Measure input event handling latency. r=bsmedberg,smaug, data-review?bsmedberg
Keywords: checkin-needed
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
See Also: → 1476772
Performance Impact: --- → P1
Whiteboard: [qf:p1]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: