1573904 - Add telemetry to measure number of bytes/time before ScriptLoadHandler::OnStreamComplete

Status: RESOLVED FIXED

(Core :: JavaScript Engine, task, P1)

Description

[Nicolas B. Pierron [:nbp]]

JavaScript sources are transferred from the Parent process to the Child process using a Channel which is filled either with network data or on-disk data.

Today, our JavaScript parser waits for the completion of the streamed bytes before starting the parser, either on the main thread or off-thread. The intent of this bug is to know how fast are the bytes made available to the child processes, before reaching the ScriptLoadHandler::OnStreamComplete, and how large are these streamed byte sequences compared to the full size of the content.

Comment 1

[Nicolas B. Pierron [:nbp]]

Attachment: Bug 1573904 - Measure the potential for a streaming parser. data-review=chutten

Comment 2

[Nicolas B. Pierron [:nbp]]

Comment on attachment 9085596 [details]
Bug 1573904 - Measure the potential for a streaming parser. data-review=chutten

Request for data collection review form

All questions are mandatory. You must receive review from a data steward peer on your responses to these questions before shipping new data collection.

1. What questions will you answer with this data?

This data is used to answer if there is any byte streamed for JavaScript requests, how large are these streamed bytes, and what is the amount of time needed to process these streamed bytes.

We want to know if we had a parser capable of processing these bytes as they are loaded, how much time we could save on page loads.

2. Why does Mozilla need to answer these questions? Are there benefits for users? Do we need this information to address product or business requirements? Some example responses:

Mozilla needs to answer these questions to decide the future of the JavaScript frontend in order to offer the better page-load performance.

3. What alternative methods did you consider to answer these questions? Why were they not sufficient?

We already know the list of JavaScript files of the top50 web sites.
However, this does not tell us how fast these bytes are streamed to child processes on user machines, nor how many of these bytes are streamed.

4. Can current instrumentation answer these questions?

No, the closest are from Necko, but they do not offer as much information as we need.

5. List all proposed measurements and indicate the category of data collection for each measurement, using the Firefox data collection categories on the Mozilla wiki.

Measurement Description	Data Collection Category	Tracking Bug #
Measure the percent of JS bytes transferred incrementally	Technical Data	Bug 1573904 ?
Measure the average transfer rate of JS bytes transferred incrementally	Technical Data	Bug 1573904 ?

6. How long will this data be collected? Choose one of the following:

I want this data to be collected for a few months initially. To first get a feeling of what we need to achieve, and potentially extend it later to be compared with other results, as a way to measure the effectiveness of a project.

7. What populations will you measure?

Nightly only.

8. If this data collection is default on, what is the opt-out mechanism for users?

opt-in (nightly channel?)

9. Please provide a general description of how you will analyze this data.

Based on other measured data of the JavaScript parser, and other proposed implementation, we want to do raw comparisons with the transfer rate.
We want to use these data to determine the estimated speed using an interruptible parser:

Current time = total bytes / parsing speed
Estimated time = total bytes * ((1 - ratio) / parsing speed + ratio * Math.min(1 / parsing speed - 1 / transfer speed, 0))

As total bytes is a factor in both cases, it should not be needed to estimate the gain, as a ratio of the Estimated time over the current time.
The parsing speed still has to be measure, but we should be able to measure it without telemetry.

10. Where do you intend to share the results of your analysis?

Likely on bugzilla, and if the project is kick-off likely in a blog post.

11. Is there a third-party tool (i.e. not Telemetry) that you are proposing to use for this data collection? If so:

No.

Comment 3

[Chris H-C :chutten]

Attachment: Data Review Request

PRELIMINARY NOTES

For future Data Review requests, please attach the filled-out request form to the bug. This facilitates review.

DATA COLLECTION REVIEW RESPONSE:

Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes. This collection is Telemetry so is documented in its definitions file Histograms.json and the Probe Dictionary.

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

Yes. This collection is Telemetry so can be controlled through Firefox's Preferences.

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

No. This collection will expire in Firefox 75.

Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 1, Technical.

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

Default on for pre-release channels only.

Does the instrumentation include the addition of any new identifiers?

No.

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

Yes.

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

Yes. :nbp is responsible for renewing or removing the collection before it expires in Firefox 75.

---

Result: datareview+

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3252b137dadf
Measure the potential for a streaming parser.  data-review=chutten r=jorendorff,chutten

Comment 5

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/3252b137dadf

Comment 6

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/releases/mozilla-beta/rev/3252b137dadf