[Memory Profiler] Table view suggestions

I'll start off by saying that the current filter support works relatively well. I love the Group filter too.
This tool really helps me deliver our game, I would be completely lost without it (if the Heap Explorer package didn't exist that is).

However, comparing 2 memory snapshots to see where there was an increase in memory is a bit clunky at the moment due to a few reasons:
* Diffing is vertical and not horizontal
Most (text) diff tools work with a horizontal diff so that you can see the stats side by side. This would be very useful in this case. Now I have to scan vertically for which values have significantly changed.

  • Applying new filters collapses the table view again.
    If I found something suspicious and I want to drill down on it, I often end up applying a new filter to clean up the view. Unfortunately, the table view completely collapses when doing that and I have to search my suspicious object again.

  • Limited filtering options.
    As there can be a HUGE amount of elements in these table views, I often find myself only caring for the top 20 big values.
    I haven't figured out a way to filter objects so that only objects with a size of 1Mb or larger are shown for example. Having that would actually help a lot with the first point (vertical diffing) as it removes the seeking by showing less values.

Kind regards,


It looks like the "Match..." filter on the

 column is not a bitfield, and it's impossible to select more than 1 match:

I'd like to ignore the "Same" category but showing both Deleted and New doesn't seem to work.

Hi and thank for for the detailed feedback and suggestions.

This is indeed something we're pondering to change. Currently the table code is not written in a way that would be flexible and maintainable enough to implement this in a reasonable time frame so most of the table code is gonna get rewritten to allow us quicker iteration speeds to build out such views.

Sadly even fixing issues such as that collapsing on changing the filters can be quite time consuming so, not sure we'll be getting to address that before the reimplementation.

That's a good call and something we'll keep in mind for the table view reimplementation :)

The Filters list is indeed (logical, not bitwise) AND compared and yeah, Diff is a non-bitfield enum value and the Match Filter currently runs on strings... So, thank you for the valuable feedback but please bear with us, cause there is a couple more fundamental things to change around here first. :/


Thank you for your reply Martin, looking forward to that redesigned version!

1 Like