- From: Paul Bakaus <pbakaus@zynga.com>
- Date: Tue, 25 Sep 2012 17:54:20 +0000
- To: "public-web-perf@w3.org" <public-web-perf@w3.org>
On 20.09.12 19:28, "Boris Zbarsky" <bzbarsky@MIT.EDU> wrote: >On 9/20/12 8:09 AM, Paul Bakaus wrote: >>> 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 :) > >Well, sure; I'm just trying to understand precisely what the desired >behavior is, for now. > >The problem is that "memory per GameObject" depends on whether there are >other GameObjects around. And on whether there are any other objects >around that GameObject shares structure with. And on whether you ever >redefine or delete properties on GameObjects. And on how many >properties GameObjects have. > >And that's just for the object representation. If you want to measure >overall memory usage due to creating a GameObject and passing it to a >function, you have to account for the sizes of inline caches that will >be generated in the process. Especially if your GameObjects are >actually somewhat polymorphic. Yes, I was worried about all the implications before :/ It also obviously differs for each implementation of a JS Engine. I think like the "GC off" feature, we should likely postpone this item and expose the total memory consumption first. However, anywhere we could differentiate *easily* between individual allocation types, we should make the distinction I.e. We could have an "images" field, a JS "field" and so on. > >> 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). > >We can always return A Number for single objects. That number is >unlikely to be in any way meaningful. :( > >> 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. > >That would have different per-object memory characteristics than a full >application that uses GameObjects, per above discussion. > >Benchmarking/measuring things is hard. :( Very hard! Unfortunately, the hardest is almost always the most rewarding. I have numerous examples of features I've proposed at a given time that were stopped from specification and implementation because of its complexity to implement, disregarding the usefulness of the feature :( > >> 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. > >OK. Note that I would too, as a C++ developer who is not low down in >the graphics code! ;) Great :) > >> 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? > >I like that list, yes. > >> 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. > >I'm not actually sure. I think the life cycles of images can be pretty >different in different UAs, for sure... (e.g. some cache scaled images >and some do not). It is this difference in implementations that makes it tricky do document. If I could write a blog post detailing "the lifecycle of an image" and being relatively sure it contains valid information for various UAs, I would have done it before :) So because of this difference, I think we need uniform developer APIs to measure certain steps in that lifecycle. > >> 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. > >I would certainly be a lot more willing to expose more information and >add more footgun APIs in such a mode. The developer tools could even >enable it automatically, perhaps? Yes, that would be even better. Let's make this happen. > >-Boris > >
Received on Tuesday, 25 September 2012 17:54:50 UTC