Intent to Ship: performance.measureMemory()

[Lutz Vahl]

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]

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 issue, https://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]

Thanks for the feedback, Philip!

 

As part of the mozilla/standards-positions issue, https://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]

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 issue, https://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]

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]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABNJt2KQAqEUw1Rai4OEUja0-gSN%3DAHTH8qn2VgOz_E_s-0rTw%40mail.gmail.com.

[Ulan Degenbaev]

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]

LGTM1 assuming that the shed is painted :)

[Chris Harrelson]

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).

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgk1%2BS2ZZNM3J1V1X4K%2B%3DVjfxRdk%2Btowo4jX78TycsGMg%40mail.gmail.com.

[Philip Jägenstedt]

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]

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]

FYI: Chrome is adding support for service/shared workers to catch up with the spec.

[Chris Harrelson]

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABNJt2LzX7%3DVpbcSD8WTxtqTUmuGi1SPC%2B4q9_N6CGW3393bGw%40mail.gmail.com.

[Ulan Degenbaev]

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]

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABNJt2Kmndkn%3DzhULkG%3DgHjZd%2BTowGCUw%3DJ-gFzRgNRAc4ci2w%40mail.gmail.com.

[Chris Harrelson]

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]

Thanks Chris! I pinged the Mozilla review thread.