[Webkit-unassigned] [Bug 107673] Web Inspector: More insight into GC pauses

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=107673





--- Comment #3 from Paul Lewis <aerotwist at chromium.org>  2013-01-31 05:42:41 PST ---
(In reply to comment #2)
> (In reply to comment #0)
> > Is there any way we can understand which parts of the developer's code are causing a lot of temporary allocations? That is, stats about which objects created by the developer were picked up in GC?
> 
> Can you elaborate on what do you mean by picked up in GC? Is it about the objects that survive scavenge pass? Or is it a set of objects that were unreachable during the pass?

The request I get from developers is that they want to see what objects (that they created) were picked up in a GC pass. So, as an example, if they were looping through an array and in each pass created a bunch of new objects, we should expect to see those get picked up by GC. Their thinking is that if they can see where their code is especially garbagey they can remedy it by making different choices in their JS.

> 
> 
> (In reply to comment #1)
> > More context:
> > 
> > At present we have GC records showing in the timeline, which is great. What it doesn't tell you is what was picked up in GC, specifically that which relates back to your code. So if you're using a lot of temporary variables or anonymous functions somewhere in your code it is very difficult to find, especially if you have a large codebase. A suggestion here might be to in some way track the allocations so that you can see the top scoring items. So in effect if a developer is looping through an array and effectively assigning the same logical function as a callback then we can point at that to say "this function is being allocated a lot".
> 
> So if we show the heap stats at point A and then at point B. Do you mean at point B in addition to total js heap size we should show how many object that were alive at point A and survived at point B + number of objects that were allocated between A and B and still alive at the point B? Or do you also see how many objects were collected since point A?

Good question. I guess what I'm driving at is identifying how garbagey (for want of a better phrase) parts of the code are. So if there's a part of my code that is run very often that makes a lot of temporary allocations that get picked up it would be helpful to know that piece of code is responsible for more garbage than other parts of my code.

So the use-case I'm getting at is not necessarily which objects survived or why so much as where the hotspots are in the code where I could try to avoid as much garbage being created.

Does that help?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.