Utilities ░ ▒ ▓ █ Heap Explorer - Memory Profiler, Debugger and Analyzer for Unity

I had two reasons:

• Unity's Memory Profiler was on Bitbucket and I wanted a familiar location for users of that tool
• I had a Bitbucket account already

 

Just an idea; at the moment, the "unknown" types are skipped, e.g., this error:

ERROR: 'System.Collections.Generic.Dictionary.Entry<System.Int32,System.Globalization.CultureInfo>[].baseOrElementTypeIndex' = -1 is out of range, ignoring. Details in second line

arrayRank=1, isArray=True, typeInfoAddress=2141349E5C0, address=21409CD3930, memoryreader=MemoryReader, isValueType=False

Do you think it would be possible instead of skipping them altogether, resolving them as a simple "object" (or some bogus type), so they still get shown in the C# Managed Objects, and we do not lose possible references to the address/from the address (if there is any)? Or would this not make any sense, since there would be no references for these objects?

 

I guess if I set the

baseOrElementTypeIndex

to

System.Object

or so, it would cause other issues, because the memory layout of the unknown object does not match the layout of System.Object.

Do you know how Unity's new MemoryProfiler handles this case?

PS: To my future self, it's caused by this issue.

 

this looks fantastic. great job!

 

Thanks for the kind words.

Don't miss to take a look at Unity Technologies new Memory Profiler. It will be or perhaps already is superior to Heap Explorer:
https://forum.unity.com/threads/new...ew-package-available-for-unity-2018-3.597271/

 

Did you ever get a chance to have a look at this issue?

 

Nope, I haven't looked at this issue any further. Unity staff wrote they wanted to change the "exclude uninitialized/unused types" behavior, in which case I believe this issue should just disappear. I'm also not sure if Heap Explorer is still used, because Unity released new Memory Profiler a while ago.

 

Heap Explorer is still way better then the Unity Momory Profiler (preview 8, atm of writing) and I use it on a regular basis; whenever I have to find memory leaks/usage. Main reasons I prefer HeapExplorer:

* Shortest path to root: UnityMemoryProfiler still doesn't have that feature
* speed: HeapExplorer is faster

So thank you very much for all the work you put into HeapExplorer, right now I'd say it is the best option to track down memory usage/leaks.

 

That's music to my ears, thanks a lot for the positive feedback and great to hear the tool proved to be useful! I'm surprised Unity's new Memory Profiler isn't light years ahead of Heap Explorer already.

One of my most important goal for Heap Explorer was to make it faster than their old memory profiler. I believe in most cases I succeeded, but I've also seen a few snapshots where the tool is also really sloooow.

What Unity version do you use? I wonder if it works with Unity 2019. Perhaps I should dig out the code and see if there is some low hanging fruit. I mean if the tool is still used...

 

Currently we're using 2019.1 but about to switch to 2019.3 soonish.

 

I remember using HeapExplorer way back and thought it was a great improvement over the Memory Profiler at the time. I had assumed that the new Memory Profiler would be better and regularly updated, however it sounds like that hasn't happened? In which case I just wanted to say i'd most likely use Heap Explorer again when I need that functionality, so its certainly not a dead tool to users.

 

That's great to read, OutOfMemory while creating a snapshot is one of the biggest problems right now. I'm looking forward to the update

 

Thanks for the kind words! It's the kind of feedback that keeps me motivated to work on these kind of things, so hearing this once in a while is great.

That's great news, sounds like you fixed this issue?!

Thank you for the info! Do you know if you use Heap Explorer internally to check if the Memory Profiling API changes still work and are backwards compatible?

 

This is the kind of feedback that motivates! I'll check if Heap Explorer is causing issues with 2019.3 and 2020.1. Hopefully they're easy to fix

I'm thinking to create a package of Heap Explorer that can be installed through Unity's Package Manager. I'll have to take a closer look at compatibility though, as I imagine Unity 2017 isn't really ready for packages and .asmdef files. At least it wasn't the last time I checked.

 

Great work. Very useful tool.
Also, this do work with Unity 2017.4.26 LTS.
if anyone is working on 2017.4 you can easily upgrade to 2017.4.26 and use it.

 

This tool has been instrumental in helping us get onto Oculus Quest - We are using 2018.4.13f1 and haven't run into any major issues.

The captures are much faster than Unity's capture tool and break down the data into a well readable format. In a perfect world, I want both of the tool's data visualizations and the speed of the heap explorer.

Thanks a lot for authoring this and keeping an eye on it over the years.

 

Any updates on Heap Explorer working with 2019.3?

 

Amazing asset, I honestly am beyond astounded on how good it is - way beyond what Unity's does in every way, shape, and form.

However, is there any way to look at the contents of a Texture2D that is not an asset?

 

How could I miss all the recent posts here?!

Thanks so much for the kind words and feedback! I'm always happy to hear if the tool was of help. I'm really astonished to receive such positive feedback, even after Unity released their new Memory Profiler.

I started to work on 2019.3 compatibility a while ago, there wasn't much of an issue with it though, or I didn't find the issues yet. Mostly editor UI styles that don't exist in 2019.3 anymore.

I'm going to release "Heap Explorer for 2019.3 and newer" as a package that can be installed through Unity's Package Manager window. I'll make the package and source code available on github when it's finished.

Unfortunately there isn't, at least no way that I'm aware of.

When I worked on Heap Explorer during 2017/2018, Unity's Memory Profiling API didn't support to collect/sent the actual native memory, where someone could reconstruct the texture data from, for example. I'm not sure if this has changed in the meantime.

Thanks for the info, I'm going to take a look at this as well. This change can be found in Unity 2020.1?

 

Ahh I see. I wonder if I could do something crazy like dumping the memory after scanning, and then finding the address of the texture and trying to find it that way.

 

If the texture uses "Read Write Enable", then a copy of that texture should be kept in main memory and probably included if you take a memory dump with visual studio, but that sounds complicated.

If you only want to take a look at the texture, then I would recommend you check out RenderDoc.

Edit: you could also just save your runtime texture as a file and look at it this way.

 

The reason I'm trying to look at a texture is because I have no clue about its origin, and I'm trying to figure it out. For some reason I have a bunch of massive (50mb) textures that show up in memory but they aren't named (I name all textures I generate) and they aren't assets. So I'm just trying to find some sort of way of figuring out what's going on with that x)

 

I this case, I would try to find then via Resources.FindObjectsOfTypeAll and just display them. For example by assigning them to a RawImage. This allows yoh to see their content.

 

Looking forward to the newer version this has been my goto for just finding things to optimize and locate leaks. Keep up the good work

 

Just wanted to drop in and say this asset is amazing and has saved my ass multiple times!

 

Just a reminder about this @Peter77

The UX of heap explorer is much better than Unity's men profiler atm, one example for me is tracking which object is responsible for a given allocation is way more understandable and easier.

Our studio will defo keep using this as long as you have the energy to keep putting into it (or until unity eventually agrees to buy you out ) so looking forward to the 19.3 upgrade as we're currently upgrading our projects to .3

 

I guess @MartinTilo would be quite interested to learn more details about this and then hopefully improve some of the Unity Memory Profiler UX.

I actually did start working on a Heap Explorer version for 2019.3, but it's been a while ago already and other things caught my interest.

I just checked and realized I didn't commit anything and now it's too long for me to remember what all these changes are I'll start this over and commit every single change to a 2019.3 branch to Bitbucket. It will not be 2019.3 ready in one go, but we'll get there eventually.

Did you run in any problems with 2019.3? Because I remember on first sight everything looked fine, but going in deeper revealed a few issues that I can't remember anymore.

Thanks for the kind words!

 

Hello! I actually need to do some memory profiling of our game today so I'll take the opportunity to do a bit of compare and contrasting between heap explorer + unity mem profiler and gather some thoughts and post 'em here

 

Okay so I think the main reason I prefer heap explorer is that it just exposes information that I care about quicker and "better"

1.) Heap explorer shows the total memory used by type, unity mem prof has the map (which is cool) but doesn't show totals, so you have to kind of guesstimate based on area use of types


2.) Heap explorer also shows you the count when you dive in, which mem profiler doesn't

(by contrast, inspecting this by eye is not easy)


3.) But yeah Martin as you guessed, the main thing I care about is "okay this memory is used, I want to know what is referencing it in the scene"
In heap explorer this is immediately present as you select an object


In Memory profiler, I have to click the "Referenced number" column number, which is both not obvious and an additional click.

That's some concrete things, in general I just feel that the heap profiler UX is a better experience, and small differences make a big enough difference to use it over the unity mem profiler.

As an aside - both the heap explorer and unity mem profiler show ~500mb used (device capture), but the device itself shows > 1gb used



What sort of things are typically untracked?

 

Ps. that being said, both tools in general are super valuable, I'm not trying to hate on unity mem profiler

 

Thank your for the comparison, always great to have something like that

I noticed the same problem. Unity's MemorySnapshot API didn't include various things at the time I created Heap Explorer. I doubt it has been fixed, because the issues I reported have been marked as "Won't fix" and "By design" ¯\_(ツ)_/¯

• https://issuetracker.unity3d.com/is...shot-nativearray-memory-is-not-captured-in-it
• https://issuetracker.unity3d.com/is...edheapsections-do-not-match-stats-in-profiler

Additionally, I've also a case that didn't make it into the public issue tracker for some reason, but it's still open:
(Case 989625) PackedMemorySnapshot: ExecutableAndDlls memory missing

 

Yeah, my current guess is streaming assets are accounted for in ways that may not be trackable, I've got a suspicion that ours is mostly down to wwise sound banks but will investigate properly

 

Ah I see, to double check my assumptions - what unity tracks is down to C/C# allocations with a call-stack that ultimately allocates from the engine, whereas DLLs can of course do this entirely outside of a malloc that is code in the engine?

Makes sense - presumably there isn't a way of doing something like:
* Unity.dll has loaded DLL's A and B
* DLL A has allocated X memory (presumably the OS' tracks this relationship?)
* Unity can query the OS for total DLL memory use for DLLs it has loaded
* Show this info in a mem capture with at least a breakdown of DLLs plus total kb belonging to them

Glad the feedback is useful and thanks for the workaround suggestion as well.

 

Heh, cool, I'll put in a feature request with our support dude - is that useful or is this somewhere in the roadmap already?

 

The Xcode allocations debugger is *sick* by the way, good for getting an idea on what the untracked memory allocations are, for us there are 350mb of metal library allocations

 

This is way better than unity memory profiler! Unity profiler just throws you random stuff that you cannot search or sort properly.

Works very well with .net 4.6

 

Referenced by could be made clickable, so i could jump to next reference

 

The "C#" icon next to the text is a clickable button that jumps to the object. This works across all lists in Heap Explorer.

• "C#" icon jumps to C# object
• "C++" icon jumps to the native object
• "S#" icon jumps to the C# static object reference

In Unity 2019.3 with the overhauled UI, it makes it harder to read these at buttons. This was more obvious in older Unity releases.

 

weird thing that neither unity memory profiler or Heap explorer not showing some objects

i did basic object counter and its showing there still objects in memory, after i load new scene, doing gc collect and Resources.unloadUnusedResources, old objects accumulating for some reason.

Code (CSharp):

1.  
2. internal static Dictionary<string, int> m_typeDictionary = new Dictionary<string, int>();
3.  
4. public BaseTransform()
5. {
6.     typeName = this.GetType().Name;
7.     objectCount++;
8.     m_typeDictionary[typeName]++;
9. }
10. ~BaseTransform()
11. {
12.     m_typeDictionary[typeName]--;
13.     objectCount--;
14. }

 

I'm sorry that it took so long, but here it finally is: Heap Explorer for Unity 2019.3 provided as an elegant Unity Package.

Download
https://github.com/pschraut/UnityHeapExplorer

What's new in 3.2?

• Moved Heap Explorer menu item from "Window > Heap Explorer" to "Window > Analysis > Heap Explorer"
  
• Removed "The MemoryProfiling API does not work with .NET 4.x Scripting Runtime" warning, because apparently Unity Technologies fixed this issue in the meanwhile.
  
• Removed Beta notice and note about Heap Explorer not working with .NET 3.5, because there is no .NET3.5 in Unity 2019.3 anymore.
• Fixed "Unable to find style 'TL SelectionBarCloseButton' in skin 'LightSkin' Layout" warning when opening Heap Explorer.
• Fixed per frame warning "null texture passed to GUI.DrawTexture" when the C# Hex Viewer was open.
• Fixed "Open Profiler" button not working due to error "ExecuteMenuItem failed because there is no menu named 'Window/Profiler'".
• Moved documentation from PDF to github. It's not complete yet, but I wanted to get this release out.
• Moved repository from bitbucket to github

 

awesome its alive! btw i been using previous version with 2019.3 and it did work just fine