1313462 - Measure event creation time to event handler start time (INPUT_EVENT_QUEUE_MS)

Status: RESOLVED DUPLICATE of bug 1341531

(Toolkit :: Performance Monitoring, defect)

Description

[:Harald Kirschner :digitarald]

Tracking spec work and implementation of the telemetry probe

Comment 1

[Georg Fritzsche [:gfritzsche]]

Do you have engineers to work on this?
Can you check what bugzilla component this bug should go into?

The Telemetry component is about the data collection system and some related tasks.

Comment 2

[Benjamin Smedberg]

How is this different from INPUT_EVENT_RESPONSE_MS, which we already have?

These bugs could really use a lot more specification. And not being filed in Toolkit:Telemetry, which is for the core submission systems and not about specific metrics.

Comment 3

[:Harald Kirschner :digitarald]

As you know, INPUT_EVENT_RESPONSE_MS includes the JS handler and possible other synchronous work executed by a handler, like forced reflows. That is great for chrome-related measures, where the Firefox team owns the code that causes the latency.

INPUT_EVENT_QUEUE_MS can tell us how long events are queued up for handling, without the impact of expensive JS execution, something the platform can actually optimize for much better and which is part of Quantum DOM.

Related, bug 1313465, extends INPUT_EVENT_RESPONSE_MS with a new probe that includes the render time.

Are there any concerns or risks with this approach that we should be aware of?

Comment 4

[Benjamin Smedberg]

> As you know, INPUT_EVENT_RESPONSE_MS includes the JS handler and possible
> other synchronous work executed by a handler, like forced reflows. That is
> great for chrome-related measures, where the Firefox team owns the code that
> causes the latency.
> 
> INPUT_EVENT_QUEUE_MS can tell us how long events are queued up for handling,
> without the impact of expensive JS execution, something the platform can
> actually optimize for much better and which is part of Quantum DOM.

Please clarify that in the user story for this bug! comment 0 was really confusing about what this was exactly.

> Related, bug 1313465, extends INPUT_EVENT_RESPONSE_MS with a new probe that
> includes the render time.
> 
> Are there any concerns or risks with this approach that we should be aware
> of?

I don't think your distinction makes a lot of sense here, for the following reasons:

* I think what we in general care about is how quickly the browser+site responds to user input. So when the user presses "A" in a text box, what they care about is how quickly the letter A actually appears on the screen, not how quickly Firefox delivers it to the web page. So as a metric of user satisfaction with input latency, the current definition makes more sense. We agree that it doesn't measure the last mile of the time between when we've finished handling the event and when it actually shows up on screen (async reflow and painting delay), so I fully support the notion of also measuring display latency, bug 1313465.

* Assuming there is more than one event in the queue, the latency for starting subsequent events is always gated on handling earlier events in the queue, whether that is content, platform, or frontend handlers. This was never intended to be a measure of frontend latency: it was always intended to be a measure of content latency.

Do you think that there's significant value-add to measure time to "before dispatch" and "after dispatch" separately? I'm skeptical.

Comment 5

[:Harald Kirschner :digitarald]

> Do you think that there's significant value-add to measure time to "before dispatch" and "after dispatch" separately? I'm skeptical.

The overall length from event to glass is the most perceivable but least actionable. We need more granularity with segments to get more actionable, which this is for.

Comment 6

[:Harald Kirschner :digitarald]

Is this part of your breakdown for input latency, :wcpan?

Comment 7

[Wei-Cheng Pan [:wcpan] [:wcp] [:legnaleurc] (left Mozilla)]

I think this is what I tempted to do in bug 1341531.
But it might be too heavy to measure all input events.

Comment 8

[:Harald Kirschner :digitarald]

Focus on the important input events is OK.

Comment 9

[Wei-Cheng Pan [:wcpan] [:wcp] [:legnaleurc] (left Mozilla)]

(In reply to :Harald Kirschner :digitarald from comment #8)
> Focus on the important input events is OK.

Does this mean bug 1341531 can be set to WONTFIX because INPUT_EVENT_RESPONSE_MS has already covered the case?

Comment 10

[:Harald Kirschner :digitarald]

Are they not different, where INPUT_EVENT_RESPONSE_MS marks the end of a dispatched JS handler and bug 1341531 marks the beginning of a dispatched handler?

Comment 11

[Wei-Cheng Pan [:wcpan] [:wcp] [:legnaleurc] (left Mozilla)]

OK, thanks for the clarification, I think now I realized the scope of bug 1341531.