Intent to Ship: performance.memory in workers

[Deng, Pan]

Primary eng/PM emails

pan....@intel.com, rsc...@chromium.org

 

Spec

Not a spec yet.

 

Summary

Add performance.memory to web workers. The functionality is the same as it is in the renderer, returning quantized memory values by default, and real values with a flag “--enable-precise-memory-info”.

 

Motivation

Developers would like to use it to have memory usage information for web workers.

 

Compatibility Risk

Low, we have performance.memory shipped for renderer, this only extends the functionality to workers.

 

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes

 

OWP launch tracking bug?

It is the feature request bug:

https://code.google.com/p/chromium/issues/detail?id=326370

 

Row on feature dashboard?

None. It is an extension of the existing performance.memory.

 

 

[Kenneth Rohde Christiansen]

When can we expect to see a specification? and has this been discussed on any standards mailing list or with other vendors?

Kenneth

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
Kenneth Rohde Christiansen
Web Platform Architect, Intel Corporation.
Phone  +45 4294 9458 ﹆﹆﹆

[PhistucK]

Frankly, I would actually unship this non standard property from regular web pages until (and if) it gets a specification.

And of course, I would not ship this to workers in the same vein.

☆PhistucK

[Elliott Sprehn]

On Friday, August 1, 2014, PhistucK <phis...@gmail.com> wrote:

Frankly, I would actually unship this non standard property from regular web pages until (and if) it gets a specification.

And of course, I would not ship this to workers in the same vein.

Indeed it is strange to ship this to more places without a spec. Are we really shipping the performance.memory API with no spec at all?

[Eric Seidel]

All the documentation I could find was:

http://docs.webplatform.org/wiki/apis/timing/properties/memory

It's not mentioned in MDN:

https://developer.mozilla.org/en-US/docs/Web/API/window.performance

[PhistucK]

Yes, the docs.webplatform.org page was created by Paul Irish, so it does not mean that it is supported or encouraged by the W3C in any way. The only reason for which I am not removing that page is my hesitation due to the slight chance there is a specification or whatever somewhere.

(We tend to remove Internet Explorer specific pages, so it makes sense to remove this one as well)

☆PhistucK

[Elliott Sprehn]

Yeah it sounds like we should get a real spec written and uploaded somewhere before we ship this or any more features of it.

[Eric Seidel]

Without a spec of somekind, we'll eventually have to remove performance.memory, so before we ship it in more places (making removal harder) this needs to be on a spec path, so as to lessen the chance that we're just adding more code we'll eventually have to remove from Chrome.

The API Owners met and agreed LGTM to ship so long as there exists some kind of spec, somewhere.  (That doesn't even need to mean in a working group).

We're not asking you to change what performance.memory does, or see its spec through years of edits, but rather just to write down what it does somewhere on the internet.

If I were you I would just copy one of the many existing spec templates, write out what you expect window.memory to do and then host that spec on github, or intel.com or chromium.org or wherever you like.

https://github.com/tabatkins/bikeshed is one example template system.

Once you've done that, post back to this intent thread, with a link to your spec, and a link to your CL where you're adding support and I'll happily LGTM your CL.

Eventually such a spec needs to move into the appropriate standards group, but we're not asking for that before shipping performance.memory on Workers.  WebPerf (http://www.w3.org/2010/webperf/) might be the right group when that time comes, it's possible folks there may have more resources for you now if you want them.

[Philip Jägenstedt]

Sorry to revive an old thread, but a year later I'm trying to document Performance.idl and WorkerPerformance.idl with spec links, and fail when it comes to performance.memory.

performance.memory remains behind an experimental runtime flag in workers, but does anyone know if anything happened on the spec side?

[Ilya Grigorik]

On Wed, Jul 8, 2015 at 12:59 PM, Philip Jägenstedt <phi...@opera.com> wrote:

Sorry to revive an old thread, but a year later I'm trying to document Performance.idl and WorkerPerformance.idl with spec links, and fail when it comes to performance.memory.

performance.memory remains behind an experimental runtime flag in workers, but does anyone know if anything happened on the spec side?

We're gathering and discussing requirements: https://docs.google.com/document/d/1tFCEOMOUg4zmqeHNg1Xo11Xpdm7Bmxl5y98_ESLCLgM/edit

No formal spec to show atm, but that's easy enough assuming we agree on what can and should be exposed.

ig

[Philip Jägenstedt]

Thanks Ilya, from that document it looks like there is some interest from Mozilla and Microsoft, although of course much that's not clear. There are two Gecko bugs where discussion has happened:

https://bugzilla.mozilla.org/show_bug.cgi?id=1124223

https://bugzilla.mozilla.org/show_bug.cgi?id=1132852

I hope that something comes of it :)

Philip 

[Ilya Grigorik]

On Thu, Jul 9, 2015 at 10:16 AM, Philip Jägenstedt <phi...@opera.com> wrote:

I hope that something comes of it :)

Yep, there is definitely interest in exposing such an API from Moz and IE side. We'll make it happen :)

[lun...@google.com]

Any updates on this? Are we planning to standardize Performance#memor? Or should we just remove it cause it is non-standard? 

[Ilya Grigorik]

Mounir put together a proposal: https://discourse.wicg.io/t/proposal-memory-pressure-api/1746

I'll defer to him on status.. :)

[Elliott Sprehn]

Fwiw the current API was never meant to solve the same problems as memory pressure notifications. It's used internally by Google apps to measure memory usage for testing and measuring the impact of changes in the wild (though I'm not sure how good it is at that given all the factors at play).

Shipping memory pressure notifications is great, but doesn't address the needs of performance.memory consumers.

[Philip Jägenstedt]

So, um, is it the case that nobody is working on a proposal that would allow us to eventually get rid of performance.memory, or perhaps on standardizing performance.memory itself?

[Ilya Grigorik]

On Fri, Feb 24, 2017 at 7:11 PM, Elliott Sprehn <esp...@chromium.org> wrote:

Fwiw the current API was never meant to solve the same problems as memory pressure notifications. It's used internally by Google apps to measure memory usage for testing and measuring the impact of changes in the wild (though I'm not sure how good it is at that given all the factors at play).

Shipping memory pressure notifications is great, but doesn't address the needs of performance.memory consumers.

Yes and no. Yes, as in I agree that it exposes different data, and "no" in that it might still enable a significant fraction of the cases + and is the best we're willing to expose. Based on discussions at previous F2F's and TPAC [1]: 

• Memory layouts change; optimizations come and go; browsers differ in how they allocate, etc. As a result, the consensus in the room (Apple, Moz, Edge, Chrome) was that we don't want to expose raw numbers... E.g. yes the page may be taking some huge amount of memory, but that in itself is not a bad thing if there is plenty of memory to go around; what matters is what happens when you're under pressure.
• There was general consensus that exposing memory pressure events is the valuable bit + it passes the privacy/security sniff test.

Apple + Edge folks were both interested in this API.

[1] https://docs.google.com/document/d/1RigHs7a4yRcVUt4fPswOZLKY_-tDlPiz8hPokBixHEk/edit#bookmark=id.46whcz4yijpn

On Mon, Feb 27, 2017 at 7:53 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

So, um, is it the case that nobody is working on a proposal that would allow us to eventually get rid of performance.memory, or perhaps on standardizing performance.memory itself?

My preference: ship memory pressure, deprecate performance.memory.

ig

[Philip Jägenstedt]

On Tue, Feb 28, 2017 at 2:10 AM Ilya Grigorik <igri...@google.com> wrote:

On Fri, Feb 24, 2017 at 7:11 PM, Elliott Sprehn <esp...@chromium.org> wrote:

Fwiw the current API was never meant to solve the same problems as memory pressure notifications. It's used internally by Google apps to measure memory usage for testing and measuring the impact of changes in the wild (though I'm not sure how good it is at that given all the factors at play).

Shipping memory pressure notifications is great, but doesn't address the needs of performance.memory consumers.

Yes and no. Yes, as in I agree that it exposes different data, and "no" in that it might still enable a significant fraction of the cases + and is the best we're willing to expose. Based on discussions at previous F2F's and TPAC [1]: 

• Memory layouts change; optimizations come and go; browsers differ in how they allocate, etc. As a result, the consensus in the room (Apple, Moz, Edge, Chrome) was that we don't want to expose raw numbers... E.g. yes the page may be taking some huge amount of memory, but that in itself is not a bad thing if there is plenty of memory to go around; what matters is what happens when you're under pressure.
• There was general consensus that exposing memory pressure events is the valuable bit + it passes the privacy/security sniff test.

Apple + Edge folks were both interested in this API.

[1] https://docs.google.com/document/d/1RigHs7a4yRcVUt4fPswOZLKY_-tDlPiz8hPokBixHEk/edit#bookmark=id.46whcz4yijpn

On Mon, Feb 27, 2017 at 7:53 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

So, um, is it the case that nobody is working on a proposal that would allow us to eventually get rid of performance.memory, or perhaps on standardizing performance.memory itself?

My preference: ship memory pressure, deprecate performance.memory.

I'm all for that if deprecation is followed by removal. Do you believe that memory pressure alone would suffice for A/B testing and other metric-y things people are doing with the current API?

Elliott, do you know the details about how the existing API is used, and what it would take to replace it fully? (Having to make code changes is fine of course, but making things impossible is not great.)

[Ilya Grigorik]

As Elliott pointed out, it's not 1:1.. but I do believe it can address some of the underlying reasons for why folks want such an API. More importantly, based on discussions at TPAC with other vendors there was no/very little appetite in exposing byte numbers; we did get a lot of nods for pressure signals.