W3C home > Mailing lists > Public > public-web-perf@w3.org > September 2012

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

From: Paul Bakaus <pbakaus@zynga.com>
Date: Mon, 17 Sep 2012 13:36:34 +0000
To: "public-web-perf@w3.org" <public-web-perf@w3.org>
Message-ID: <CC7CF0F0.147A3%pbakaus@zynga.com>


On 17.09.12 13:28, "Boris Zbarsky" <bzbarsky@MIT.EDU> wrote:

>On 9/17/12 6:09 AM, Paul Bakaus wrote:
>> On 13.09.12 13:47, "Boris Zbarsky" <bzbarsky@MIT.EDU> wrote:
>>> OK.  But the point is that creating a single object and measuring its
>>> memory usage won't tell you what you want here, right?  You actually
>>> have to create 100 objects and ask how much memory those are using as a
>>> set.  Or something?
>> 
>> Correct. We will still need to go that route, but can automate then
>> automate it inline.
>
>I'm not following.
>
>Maybe you can give an example of how you'd expect to use the API you're
>proposing here?  Because I'm not seeing it so far.

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. I track and log memory stamps: When 50 objects are around, I
create a "memory timestamp", when 100 are around, and so on. This way, I
can understand the characteristics of how much memory is consumed by those
objects.

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.

Today, whenever memory usage goes off the roof, we have to painstakingly
trace the app for days and sometimes weeks. It is a real issue.


>
>>> My point is that this presupposes definitions for "memory" and
>>>"consume"
>>> that are not obvious to me.
>> 
>> 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. 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. 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.

>
>> It needs to be obvious as a web developer to say "ah of course, that
>>texture makes
>> my app slow because of a,b,c.".
>
>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.

>
>> On mobile platforms I don't think so  is there a mobile browser that
>> doesn't "freeze" tabs that are not in focus?
>
>As far as I know, there are (e.g. Gecko will throttle but not
>immediately freeze background tabs).  Certainly this is a situation
>subject to change on the timescales on which these sorts of APIs would
>land in browsers.

True  that is a general problem with some of my proposals. The GC thing
below will also hopefully be a temporary concern.

>
>> Yes, sorry, you are right. The pause time is what interests me, not the
>> total duration of the GC.
>
>OK.  Some sort of API for exposing recent pause times is not unreasonable.

Excellent :)

>
>> Global GC is hazardous, as you should only be able to disable GC in
>> situations where, theoretically at least, you are under full control.
>>But
>> I can see your points. I think my proposal to disable GC completely is
>>the
>> last thing we should try, if all other attempts of educating the user
>>how
>> to keep main thread pauses below a certain threshold fail.
>
>OK, we can agree on that.  Let's do the other stuff and then see where
>we are.  ;)
>
>> I also agree that people tend to know what's going on and in reality
>> don't. This is a huge problem we need to overcome. If anything, I teach
>>my
>> co-workers how browsers work  and even though I had a lot of exposure
>> with vendors and internals, I still feel very green and insecure about
>> certain ways to optimize.
>
>If it makes you feel any better, so do browser developers.  ;)

It does make me feel slightly better ;) Thanks!

Cheers,
Paul

>
>-Boris
>
>
Received on Monday, 17 September 2012 13:37:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 17 September 2012 13:37:04 GMT