- From: Paul Bakaus <pbakaus@zynga.com>
- Date: Thu, 13 Sep 2012 11:14:35 +0000
- To: "public-web-perf@w3.org" <public-web-perf@w3.org>
Hey Boris, On 12.09.12 22:51, "Boris Zbarsky" <bzbarsky@MIT.EDU> wrote: >On 9/12/12 9:02 PM, Paul Bakaus wrote: >> * We donšt know how much memory a newly created object or function >> allocates > >It depends on how it's allocated. Furthermore, data structures are >shared between elements, so allocating N objects that are sort of >similar does not use N times the memory for a single object... > >What information do you really want to gather here? Precisely the fact that similar structures don't "copy" memory, but some others do, is why we'd like to find out. Let's say I create 100 similar formed objects (objects on a map), and only the x/y coordinates change I'd like to know how much more of a memory footprint additional of these objects consume to better gauge how large my total "pool" of objects should be. Right now, the only thing we can do is create a JS test and then watch the memory usage of the tab/browser rise. > >> * We donšt know when an uncompressed, compressed or both >> representations of an image is kept in memory and for how long > >Some of this is implementation details that are hard to expose to script >in sane ways. Starting with the concept of "in memory". For example, >Gecko on some OSes doesn't even store decompressed images in its own >address space; they're stored in the X process. And/or stored in VRAM >instead of RAM, independently of the X thing. > >Exposing some overall statistics on this would probably be ok. Exposing >detailed information about a specific image that's expected to be >available synchronously and always correct is something I would be >opposed to, because it precludes parallelization opportunities that I >think we want to take. I understand your argument and it is one I've been hearing from many browser developers. We have the specific issue that we can only have a given amount of textures loaded at the same time so imagine a game that has multiple levels and assets that to some extend change per level. We need to be able to reliably understand how much memory the assets consume that are required for that level (all images that will be used throughout the level) and need to be able to unload these that we do not need right now. Unfortunately, this is an urging real world problem. > >> We need information on when layers are created, destroyed and >> recomposited. > >This happens asynchronously, in many cases in a different process or >different thread. Synchronously exposing information about this to the >DOM would be highly undesirable as we try to parallelize layout engines. > Async notifications are likely possible. Async notifications are totally fine. > >> 4. Total available memory > >There are some fingerprinting concerns here. And of course as you say >the number gives you basically 0 in the way of guarantees... Even though it doesn't guarantee anything, on most mobile platforms today, there's a single app usage pattern, meaning you use one app at a time, so it is reasonably safe to assume that memory consumption won't dramatically increase by another app thread on a device while browsing your site. > >> * Understand the execution interval of GC (i.e an event triggered on >> the window) > >What does this mean in a world where parts of GC happen async on >separate threads? I wasn't aware of the fact that GC can happen async nowadays and have never seen it in action. If so, that would mean that GC would never block the UI thread, in which case I'm happy remaining in the dark about these events. So in short as soon as this is the case across browsers, I don't need this feature any longer. > >> * Understand the time a GC took (in order to optimize our framerate >> against it, could be reported through the same event) > >Same question. Same answer :) It is is happening on the UI thread, we need to know. > >> * Disable GC and only trigger it manually > >You would have to do a good bit of convincing on this one, I think. My >first reaction being somewhere between "heck, no" and "no way". ;) >This is a huge footgun, and one incredibly likely to get misused all >over the place. Very true. This one can only be implemented if all of the above is implemented - meaning, when the user has total awareness of what code or asset uses memory (and when), when he is in theoretical full control, this option makes sense. At this point, I could see this scenario: 1) I know the total number of assets my game requires 2) I do all the asset/code pooling myself 3) I'm reasonably confident to be able to keep the heap at a certain level on my own 4) I want no-compromise, maximum execution performance This is a scenario where I'd like to try disabling the GC. You know this better than I though is this technically simple? Maybe we could produce a test build of a browser with that feature and we could prototype a little to see if it is worth exploring that path? Thanks for your feedback! > >-Boris >
Received on Thursday, 13 September 2012 11:15:03 UTC