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

On 20.09.12 19:28, "Boris Zbarsky" <bzbarsky@MIT.EDU> wrote:

>On 9/20/12 8:09 AM, Paul Bakaus wrote:
>>> In what sense?  Just in the sense that you log total application memory
>>> usage before and after creating these objects?
>> 
>> Well, that is one way to do it. It would be hard to go that route in a
>> live app, where lots of different things are instantiated along. I'd
>> rather have an API like "typeof GameObject", I.e. "memoryof
>>GameObject". I
>> realize I might be asking for something impossible here, but it doesn't
>> hurt to ask :)
>
>Well, sure; I'm just trying to understand precisely what the desired
>behavior is, for now.
>
>The problem is that "memory per GameObject" depends on whether there are
>other GameObjects around.  And on whether there are any other objects
>around that GameObject shares structure with.  And on whether you ever
>redefine or delete properties on GameObjects.  And on how many
>properties GameObjects have.
>
>And that's just for the object representation.  If you want to measure
>overall memory usage due to creating a GameObject and passing it to a
>function, you have to account for the sizes of inline caches that will
>be generated in the process.  Especially if your GameObjects are
>actually somewhat polymorphic.

Yes, I was worried about all the implications before :/ It also obviously
differs for each implementation of a JS Engine. I think like the "GC off"
feature, we should likely postpone this item and expose the total memory
consumption first. However, anywhere we could differentiate *easily*
between individual allocation types, we should make the distinction ­ I.e.
We could have an "images" field, a JS "field" and so on.

>
>> Yes, but I'd like it to be more precise, not measured against the total
>> memory heap (as other stuff could fill up other memory at the same time,
>> unless I write a specific test for GameObjects - which I will happily
>>take
>> as alternative though, if we can't make measuring memory on single
>>objects
>> work).
>
>We can always return A Number for single objects.  That number is
>unlikely to be in any way meaningful.  :(
>
>> It presumes I know how to track GameObjects and there individual memory
>> usage. But your way of comparing against the total memory consumption
>> might work out as well, just not in a live game - as mentioned above, we
>> would need to write an isolated test that only instantiates GameObjects.
>
>That would have different per-object memory characteristics than a full
>application that uses GameObjects, per above discussion.
>
>Benchmarking/measuring things is hard.  :(

Very hard! Unfortunately, the hardest is almost always the most rewarding.
I have numerous examples of features I've proposed at a given time that
were stopped from specification and implementation because of its
complexity to implement, disregarding the usefulness of the feature :(

>
>> Ah sorry about that. Mh, good question. I think if there's constant
>> transfer between one memory space to another, and this swapping could
>>be a
>> bottleneck, then yes - we'd also like to know about them individually
>>and
>> differentiate between them.
>
>OK.  Note that I would too, as a C++ developer who is not low down in
>the graphics code! ;)

Great :)

>
>> 1) Why is my texture in RAM, and what does it mean for my app's
>> performance?
>> 2) Why is my texture in VRAM, and what does it mean for my app's
>> performance?
>> 3) How do I get my texture into either? What are the pro's and cons?
>> 4) How can I automate tests in my live app or game to find out when
>> something goes wrong, I.e. Too much textures are uploaded to video
>>memory?
>
>I like that list, yes.
>
>> Yes, I understand. I think for once, we will need to educate web
>> developers about the "lifecycle of an image" on a web app, and what
>>could
>> all happen to it. Then, we need to look at all current browser
>> implementations and if and when they differ, and try to answer above's
>> questions for our target developers. If we can, we have the right set of
>> APIs in place. I am not sure how much of it is simply education, and how
>> much can only be solved in new APIs. I need your help on answering that
>> question.
>
>I'm not actually sure.  I think the life cycles of images can be pretty
>different in different UAs, for sure... (e.g. some cache scaled images
>and some do not).

It is this difference in implementations that makes it tricky do document.
If I could write a blog post detailing "the lifecycle of an image" and
being relatively sure it contains valid information for various UAs, I
would have done it before :) So because of this difference, I think we
need uniform developer APIs to measure certain steps in that lifecycle.

>
>> One idea both Tobie and I had was a "developer" mode that can be enabled
>> easily in every browser. We would be able to expose fingerprintable, and
>> all sorts of debugging APIs that will come and go this way, without
>> risking too much. If all vendors would work together on this one, if
>>would
>> be highly valuable to us devs.
>
>I would certainly be a lot more willing to expose more information and
>add more footgun APIs in such a mode.  The developer tools could even
>enable it automatically, perhaps?

Yes, that would be even better. Let's make this happen.

>
>-Boris
>
>

Received on Tuesday, 25 September 2012 17:54:50 UTC