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

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.

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

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

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

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

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

-Boris

Received on Monday, 17 September 2012 11:29:21 UTC