Re: [agenda] Web Performance WG Teleconference #81 Agenda 2012-09-12

On 9/12/12 9:02 PM, Paul Bakaus wrote:
>   * We don’t know how much memory a newly created object or function
>     allocates

It depends on how it's allocated.  Furthermore, data structures are 
shared between elements, so allocating N objects that are sort of 
similar does not use N times the memory for a single object...

What information do you really want to gather here?

>   * We don’t know when an uncompressed, compressed or both
>     representations of an image is kept in memory and for how long

Some of this is implementation details that are hard to expose to script 
in sane ways.  Starting with the concept of "in memory".  For example, 
Gecko on some OSes doesn't even store decompressed images in its own 
address space; they're stored in the X process.  And/or stored in VRAM 
instead of RAM, independently of the X thing.

Exposing some overall statistics on this would probably be ok.  Exposing 
detailed information about a specific image that's expected to be 
available synchronously and always correct is something I would be 
opposed to, because it precludes parallelization opportunities that I 
think we want to take.

> We need information on when layers are created, destroyed and
> recomposited.

This happens asynchronously, in many cases in a different process or 
different thread.  Synchronously exposing information about this to the 
DOM would be highly undesirable as we try to parallelize layout engines. 
  Async notifications are likely possible.

>     4. Total available memory

There are some fingerprinting concerns here.  And of course as you say 
the number gives you basically 0 in the way of guarantees...

>   * Understand the execution interval of GC (i.e an event triggered on
>     the window)

What does this mean in a world where parts of GC happen async on 
separate threads?

>   * Understand the time a GC took (in order to optimize our framerate
>     against it, could be reported through the same event)

Same question.

>   * Disable GC and only trigger it manually

You would have to do a good bit of convincing on this one, I think.  My 
first reaction being somewhere between "heck, no" and "no way".  ;) 
This is a huge footgun, and one incredibly likely to get misused all 
over the place.

-Boris

Received on Wednesday, 12 September 2012 20:51:28 UTC