1571612 - Collect Style/Layout Flush Requests per Flush and Flushes per Tick

Status: RESOLVED FIXED

(Core :: Layout, task)

Description

[u480271]

The rendering team is interested in collecting telemetry to determine if effort to optimize layout is required and where that effort should be focused.

To assess if too many flushes are happening, we should collect telemetry on the number of pending flush requests per flush and flushes per nsRefreshDriver::Tick. We expect that lots of 1 request/1 flush is bad, but hundreds of requests/1 flush to be good, and even better would be 0 flushes before nsRefreshDriver::Tick.

Comment 1

[u480271]

Attachment: Bug 1571612 - P1: Split FlushType::Style and FlushType::Frame.

Comment 2

[u480271]

Attachment: Bug 1571612 - P2: Collect flush req and flush telemetry.

Collect telemetry for the number of pending style and layout flush requests per
flush and the number of style and layout flushes per nsRefreshDriver::Tick. A
style flush reports only style requests, but a layout flush reports style and
layout requests since flushing layout implies a style flush also.

Comment 3

[u480271]

try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=a05a4bdfd55c5f420eab6c4ea81ca6fc3c48f383

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/150bb943857d
P1: Split FlushType::Style and FlushType::Frame. r=heycam
https://hg.mozilla.org/integration/autoland/rev/272503e99b08
P2: Collect flush req and flush telemetry. r=heycam

Comment 5

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/150bb943857d
https://hg.mozilla.org/mozilla-central/rev/272503e99b08

Comment 6

[Cameron McCormack (:heycam)]

Attachment: retrospective data review request

Comment 7

[Tim Smith (inactive) 👨‍🔬 [:tdsmith]]

Comment on attachment 9128032 [details]
retrospective data review request

lgtm; thanks!

1) Is there or will there be **documentation** that describes the schema for the ultimate data set in a public, complete, and accurate way?

Yes, in Histograms.json and the probe dictionary.

2) Is there a control mechanism that allows the user to turn the data collection on and off?

Yes, the Firefox telemetry opt-out.

3) If the request is for permanent data collection, is there someone who will monitor the data over time?

n/a

4) Using the **[category system of data types](https://wiki.mozilla.org/Firefox/Data_Collection)** on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 1, technical data

5) Is the data collection request for default-on or default-off?

Default-on

6) Does the instrumentation include the addition of **any *new* identifiers** (whether anonymous or otherwise; e.g., username, random IDs, etc.  See the appendix for more details)?

No.

7) Is the data collection covered by the existing Firefox privacy notice?

Yes.

8) Does there need to be a check-in in the future to determine whether to renew the data?

:heycam is responsible for renewing the collection.

9) Does the data collection use a third-party collection tool?

No.