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

On 18.09.12 04:45, "Boris Zbarsky" <bzbarsky@MIT.EDU> wrote:

>On 9/17/12 9:36 AM, Paul Bakaus wrote:
>> Sure. Let's say I have a constructor called "GameObject". Over the life
>> time of a game session, thousands of these game objects are created and
>> destroyed. I track their memory usage separated from the rest of the
>> application.
>
>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 :)

>
>> I track and log memory stamps: When 50 objects are around, I
>> create a "memory timestamp", when 100 are around, and so on.
>
>Sounds like what I said above, yes.

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

>
>> Now the crucial part ¡© a junior dev comes in and alters the GameObject
>> constructor in a way it is not well formed any longer, and I.e. V8
>>cannot
>> create hidden classes for it any more. At this point, in my automated
>>tool
>> that tracks memory events on GameObject's, I will observe an immediate
>> spike, and I automatically know what in my app has been causing it.
>
>So this presumes you already know to track the GameObjects, and the only
>problem is that you have no API for asking for your total memory
>consumption?

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.
Better than nothing though!

>
>>>> Fair point. For memory, I'm differentiating between something that
>>>> resembles a "disk", and actual RAM (high-performance, non-persistent
>>>> buffers).
>>>
>>> Are you differentiating between different types of "memory" by that
>>> definition that can fill up independently and are not interchangeable?
>>
>> That's probably one way to describe it.
>
>I think we're talking past each other...  I was asking whether two
>non-interchangeable pieces of "high-performance, non-persistent" memory
>that are not interchangeable are things you want to differentiate between.

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.

>
>> Most web developers only understand "image goes from this space to this
>>memory space, making it
>> fast. The transfer from one space to another is slow. If high-speed
>>memory
>> space is full, OS tries to swap lots of old stuff between the two
>>spaces,
>> making everything slow". We don't care, and should not care, about
>> details.
>
>Does RAM vs VRAM count as "details"?  Note that moving between the two
>can be pretty slow.

That's a good use case. As mentioned above, we want to know about this
scenario and differentiate, as it might become a real perf bottleneck. All
I'm saying is that as a developer, I'm not very interested (well I
personally am, but that is a different story..) in the difference of RAM
and VRAM and why it exists, but I am definitely interested about why it
could make my app slow. Not sure how to describe this better, I hope this
makes somewhat sense.

So short version ¡© these do not count as details and we should be able to
understand them, as it is critical to understand performance in our apps.


>
>> This is why I was trying to explain the web developers view. Web
>> developers mainly observe - we observed that if a texture is loaded into
>> RAM, it will be drawn faster.
>
>And my point is that there are different "RAM"s that a texture can live
>in, and the drawing performance is different depending on which of those
>it lives in.

Good point. Help us expose this information and make it available to web
developers. Help web developers get a clue, helping them to answer these
questions:

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?

>
>>> OK.  So that could be because it's too big to fit in RAM, too big to
>>>fit
>>> in various cache levels, etc, right?
>>
>> Yes, exactly. We simply need to know why we make our games and apps
>>slow.
>> We need the right APIs and tools to protect us and learn what's
>>important.
>
>OK.  Note that these APIs and tools don't necessarily exist for "native"
>apps either.  Determining what CPU cache utilization is looking like and
>why is ... somewhat involved in all cases I know of.
>
>I'd really like to understand what sets of information lacks we are or
>are not trying to solve here, basically.  "Why is this slow?" is a much
>more complicated question than "How much RAM do I have?" to answer.  :(

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.

>
>> True ¡© that is a general problem with some of my proposals. The GC thing
>> below will also hopefully be a temporary concern.
>
>I'd _really_ like to not add APIs to the web platform permanently if
>they only address temporary concerns.  Just for general reference.  ;)

Ha, totally. I'm trying to be reasonable, but I realize that things will
change, and a lot of it is low level implementation that just happens to
be quite similar for all browsers right now.

I am, for instance, not proposing an API to understand when something is
painted on a "layer" in WebKit, as this would be to specific to a single
engine (Trident for instance always paints through Direct2D and doesn't do
the layer abstraction, afaik).

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.

>
>-Boris
>

Received on Thursday, 20 September 2012 12:09:39 UTC