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

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?

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

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

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

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

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

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

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

-Boris

Received on Tuesday, 18 September 2012 02:46:10 UTC