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

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, 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.  :(

> 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! ;)

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

> 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?

-Boris

Received on Thursday, 20 September 2012 17:29:15 UTC