Intent to Ship: performance.measureMemory()

266 views
Skip to first unread message

Lutz Vahl

unread,
Jan 8, 2021, 5:23:33 AM1/8/21
to blink-dev

Happy new Year! 🎆



Contact emails

ul...@google.com, va...@chromium.org


Explainer

https://github.com/WICG/performance-measure-memory


Specification

https://github.com/WICG/performance-measure-memory


Design docs

https://web.dev/monitor-total-page-memory-usage

https://github.com/WICG/performance-measure-memory/blob/master/ORIGIN_TRIAL.md


Summary

The feature adds a performance.measureMemory()* function that estimates the memory usage of the web page in case the page is currently isolated (e.g. on Desktop).


After the full launch the API will be gated behind COOP/COEP thus the web site needs to be crossOriginIsolated to use the API.


* There is an ongoing naming discussion if the name needs to be changed to reflect the API feature better: https://github.com/WICG/performance-measure-memory/issues/11#issuecomment-756667712

Blink component

Blink>PerformanceAPIs


Search tags

JavaScript memory, crossOriginIsolated


TAG review

https://github.com/w3ctag/design-reviews/issues/386


TAG review status

Issues addressed


Link to origin trial feedback summary

OT feedback was addressed during OT and OT was extended to verify the changes. Feedback report from Google Workspace is shared publicly


Facebook tested the API as well during the OT and feedback is posted on github

https://github.com/WICG/performance-measure-memory/issues/24


Risks

Interoperability and Compatibility

  The actual memory usage of a web page is not comparable across browsers.


The granularity of memory usage breakdown will differ across browsers.



Gecko: Under consideration 

https://github.com/mozilla/standards-positions/issues/281


WebKit: No signal

https://lists.webkit.org/pipermail/webkit-dev/2020-April/031160.html


Web developers: Positive (https://docs.google.com/document/d/1u21oa3-R1FhHgrPsh8-mpb8dIFVj60wcFiM5FFrfIQA/edit#heading=h.6si74uwp7sq8) Developers from Gmail, Google Docs/Slides/Sheet, Facebook, YouTube contributed use cases for a memory measurement API. The proposal was presented at WebPerf WG F2F June 2019 meeting with positive feedback from developers.


Ergonomics

None


Activation

None


Security

The API relies on crossOriginIsolated based on COOP and COEP for security.


See https://github.com/ulan/performance-measure-memory#security-considerations



Is this feature fully tested by web-platform-tests?

Yes


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1049093


Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1048745


Sample links

https://wpt.fyi/results/measure-memory?label=master&label=experimental&aligned&q=measure-memory


Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5685965186138112


Links to previous Intent discussions

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/zxCKzulX424/m/bb1QR23rAQAJ



Philip Jägenstedt

unread,
Jan 11, 2021, 5:16:03 AM1/11/21
to Lutz Vahl, blink-dev
Happy new year, Lutz!

I've skimmed over the spec, tests and discussions with other vendors and have a few small questions.

As part of the mozilla/standards-positions issuehttps://github.com/WICG/performance-measure-memory/issues/5 was filed but remains open. Is that something that's important to resolve before shipping?

Looking at https://wpt.fyi/results/measure-memory, I see that all tests are marked tentative. Should that still be the case? If they were written before https://wicg.github.io/performance-measure-memory/ existed, then now the only ones that should still be tentative are ones which go beyond what the spec requires. If there are tests like that remaining, it would be good to ensure issues are filed, and that none of those issues are important to resolve before shipping.

I'm also not sure I understand why the tests are failing on wpt.fyi but seem to all pass in Chromium. Does --enable-experimental-web-platform-features not enable this in Chrome Dev, perhaps because it's in an origin trial?

Best regards,
Philip

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH0ixBO67k7P-JSkAUzT7fkre9q1RsaD3Ljb4y0o93Y9gU1Wmw%40mail.gmail.com.

Ulan Degenbaev

unread,
Jan 11, 2021, 8:53:13 AM1/11/21
to Philip Jägenstedt, Lutz Vahl, blink-dev
Thanks for the feedback, Philip!
 
As part of the mozilla/standards-positions issuehttps://github.com/WICG/performance-measure-memory/issues/5 was filed but remains open. Is that something that's important to resolve before shipping?
There is a PR in review for that issue. I'll ping this thread once it is merged.

Thanks for clarifying what tentative in WPT means. I thought that we can promote tests from tentative only after shipping. I uploaded a renaming CL.

Most of the failing tests on wpt.fyi will be fixed in the next Chrome Dev release: there was a CL that updated the tests and the implementation to the latest spec. Currently the updated tests are being tested with the old implementation. (A couple of tests are timing out because the API is not guaranteed to return the result immediately. In Chrome we work around that by passing a flag that forces eager measurement. I guess we need to remove these tests as slow to get wpt.fyi green.)

Cheers,
Ulan.

Philip Jägenstedt

unread,
Jan 12, 2021, 10:20:51 AM1/12/21
to Ulan Degenbaev, Lutz Vahl, blink-dev
On Mon, Jan 11, 2021 at 2:53 PM Ulan Degenbaev <ul...@google.com> wrote:
Thanks for the feedback, Philip!
 
As part of the mozilla/standards-positions issuehttps://github.com/WICG/performance-measure-memory/issues/5 was filed but remains open. Is that something that's important to resolve before shipping?
There is a PR in review for that issue. I'll ping this thread once it is merged.

Great, thank you! Just so that there's no misunderstanding, you'd like to get it reviewed and merged before shipping, putting this intent on hold?

Thanks for clarifying what tentative in WPT means. I thought that we can promote tests from tentative only after shipping. I uploaded a renaming CL.

Thanks! That rename has landed now, and should soon be reflected on wpt.fyi too. (Just spotted that the README could also do with an update.)
 
Most of the failing tests on wpt.fyi will be fixed in the next Chrome Dev release: there was a CL that updated the tests and the implementation to the latest spec. Currently the updated tests are being tested with the old implementation. (A couple of tests are timing out because the API is not guaranteed to return the result immediately. In Chrome we work around that by passing a flag that forces eager measurement. I guess we need to remove these tests as slow to get wpt.fyi green.)

I see, just a recent change that hasn't reached Dev yet, no mystery then :)

Ulan Degenbaev

unread,
Jan 12, 2021, 3:27:54 PM1/12/21
to Philip Jägenstedt, Lutz Vahl, blink-dev
The PR has been merged. We will keep the issue open to give Mozilla a chance to respond.

I think this I2S can proceed without waiting for the resolution of the issue because the API will not change fundamentally. The only things that may change are how many bytes we report and how many entries we include in the resulting breakdown list. Both can be adjusted afterwards without breaking the user code because we have a mechanism for preventing hardcoding.

Just spotted that the README could also do with an update.
Thanks for catching this! A fix is in review. 

Cheers,
Ulan.

Yoav Weiss

unread,
Jan 12, 2021, 4:21:23 PM1/12/21
to Ulan Degenbaev, Philip Jägenstedt, Lutz Vahl, blink-dev
One more open issue is https://github.com/WICG/performance-measure-memory/issues/11, bikeshedding a property name: "bytes" vs. "userAgentSpecificBytes"
This was discussed at the WebPerfWG last week, with almost-consensus of the folks present to go with "bytes" (with personal preference of the Sean Feng from Mozilla in the other direction).
After that, on the issue, Smaug from Mozilla sided with Sean with a preference towards "userAgentSpecificBytes", but it seems like it'd require a bit more time to reach conclusions.

Ulan - in case this is approved for M89, would you be open to backporting a rename, if that's where that thread would land? 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Ulan Degenbaev

unread,
Jan 12, 2021, 5:32:55 PM1/12/21
to Yoav Weiss, Philip Jägenstedt, Lutz Vahl, blink-dev
It seems that the thread is moving in the direction of adding "UASpecific". I will prepare CLs for that and backport if needed.

Can I2S proceed assuming that the bikeshedding issue will be resolved?

Cheers,
Ulan.

Yoav Weiss

unread,
Jan 12, 2021, 5:49:16 PM1/12/21
to Ulan Degenbaev, Philip Jägenstedt, Lutz Vahl, blink-dev
LGTM1 assuming that the shed is painted :)

Chris Harrelson

unread,
Jan 12, 2021, 6:08:41 PM1/12/21
to Yoav Weiss, Ulan Degenbaev, Philip Jägenstedt, Lutz Vahl, blink-dev
LGTM2 to ship once there is WG consensus on the name and issue 11 is closed.

I also see that Olli commented on the Mozilla standards position issue about this spec, so hopefully this will result in a positive Mozilla position on the spec (currently no position chosen).

Philip Jägenstedt

unread,
Jan 13, 2021, 4:37:31 AM1/13/21
to Chris Harrelson, Yoav Weiss, Ulan Degenbaev, Lutz Vahl, blink-dev
LGTM3 to ship, but my LGTM isn't blocked on any particular resolution to https://github.com/WICG/performance-measure-memory/issues/11. As I just commented it seems odd in one way to claim only the types as UA-specific, but I defer entirely to Lutz and Ulan about how to resolve the situation. Hopefully the issue can be resolved in a way that everyone is happy with, of course.

Ulan Degenbaev

unread,
Jan 13, 2021, 12:50:45 PM1/13/21
to Philip Jägenstedt, Chris Harrelson, Yoav Weiss, Lutz Vahl, blink-dev
Thanks all for reviewing! And thanks Yoav and Philip for chiming in the discussion in issue 11.

We settled on the measureUserAgentSpecificMemory/types option. I landed the necessary changes in Chromium and WICG.

Cheers,
Ulan.

Ulan Degenbaev

unread,
May 19, 2021, 4:06:03 AM5/19/21
to Philip Jägenstedt, Chris Harrelson, Yoav Weiss, Lutz Vahl, blink-dev
FYI: Chrome is adding support for service/shared workers to catch up with the spec.

Chris Harrelson

unread,
May 19, 2021, 11:11:01 AM5/19/21
to Ulan Degenbaev, Philip Jägenstedt, Yoav Weiss, Lutz Vahl, blink-dev
Hi Ulan,

I think this kind of addition needs a new intent. We've done that across the board for other times that APIs end up being exposed in new worker contexts. Another reason is whether there is any change in positions of the other browsers, or opinion from them--or the web standards community more generally--about this extension.

Chris



Ulan Degenbaev

unread,
May 19, 2021, 11:16:48 AM5/19/21
to Chris Harrelson, Philip Jägenstedt, Yoav Weiss, Lutz Vahl, blink-dev
Hi Chris,

The service/shared worker was already in the spec and in the explainer at the time we sent the original intent.
Chrome did not support them at the time and it is fixed now by the CL I linked. Since there is no spec change, do we need a new intent?

Cheers,
Ulan.

Chris Harrelson

unread,
May 19, 2021, 11:20:24 AM5/19/21
to Ulan Degenbaev, Philip Jägenstedt, Yoav Weiss, Lutz Vahl, blink-dev
I see. Good point. And the other browser vendors were I presume already aware? Were there any concerns specific to workers at the time?

Also, it sounds like the only reason we didn't ship for workers at the time was that we didn't have an implementation yet, is that correct?

Chris

Chris Harrelson

unread,
May 19, 2021, 11:33:27 AM5/19/21
to Ulan Degenbaev, blink-dev
With those updates, LGTM to go ahead (no need to wait for 3 LGTMs IMO).

Also, please ping the mozilla standards issue to see if we can make progress there, thanks!

On Wed, May 19, 2021 at 8:23 AM Ulan Degenbaev <ul...@google.com> wrote:
> I see. Good point. And the other browser vendors were I presume already aware? Were there any concerns specific to workers at the time?
Yes. We discussed the scope of shared/service workers here: https://github.com/WICG/performance-measure-memory/issues/4


> Also, it sounds like the only reason we didn't ship for workers at the time was that we didn't have an implementation yet, is that correct?
That's right.

Ulan Degenbaev

unread,
May 19, 2021, 11:34:41 AM5/19/21
to Chris Harrelson, blink-dev
Thanks Chris! I pinged the Mozilla review thread.
Reply all
Reply to author
Forward
0 new messages