From bug 1148822, quick attempt at rendering allocations over time. Don't know if this is useful, or if it should be for performance tool or memory tool, but just putting it here.

and here is the hacky proof of concept

What are the units here? What is the x-axis? What is the y-axis? We talked about adding an allocation heat map in London, but I don't know if we ever filed bugs.

What questions are you trying to answer with this graph?

Its number of allocations in time domain; afaict, can't get the size of these allocations currently with the memory actor. Its grouped in chunks based off of polling, currently at 200ms, so multiplying alloc counts by 5 we'd have allocs per second for allocation pressure, though might be better represented as KB/s. What is it trying to answer? Heavy allocation actions, spawned from ideas in bug 1148822 -- I do not know if this is useful yet, or made redundant if we make the allocations flame chart/graph not in the time domain, but wanted a home for the feature regardless for now

I think we want to graph rate of allocations, not the allocations themselves. Its ok to alloc, but if you alloc too fast, that's what forces a blocking GC. Should probably overlay GC markers as well once bug 1137527 lands.

Just to nitpick, i'd like to see this part of the same memory graph, not as a bar graph underneath. Too much wasted space.

(In reply to Nick Fitzgerald [:fitzgen] from comment #5) > I think we want to graph rate of allocations, not the allocations > themselves. Same thing, just in line graph form, I think is what you're asking for? (In reply to Victor Porof [:vporof][:vp] from comment #6) > Just to nitpick, i'd like to see this part of the same memory graph, not as > a bar graph underneath. Too much wasted space. Agreed -- again this is a quick ugly hack. Especially if this was in a line graph, would be pretty straight forward to layer them both in the same graph (although the LineGraphWidget atm does not support that, and would need to do something about the legends/labels min/max marks too)

And probably should be rate of allocation size, not by count, right? What's more likely to cause a GC, lots of small objects, or a handful of large objects? Would you rather fight 100 duck-sized horses or one horse-sized duck?

(In reply to Jordan Santell [:jsantell] [@jsantell] from comment #8) > And probably should be rate of allocation size, not by count, right? What's > more likely to cause a GC, lots of small objects, or a handful of large > objects? Would you rather fight 100 duck-sized horses or one horse-sized > duck? Yes, but that will have to wait on bug 1068988

Is this valuable to have in realtime? If not, then we can move forward with bug 1196862 and serve allocations after the recording is finished, which would significantly increase speed, I think, as this is a lot of data going over the wire.

Nah, not needed to be realtime, IMO.

Triaging. Filter on ADRENOCORTICOTROPIC (yes).