My first profile result and I'm puzzled.

Hi Chris,

This sounds like you are capturing the Editor or maybe the play-mode Player running in the Editor? Profiling the play-mode Player (for CPU or memory profiling) will result in skewered results. The Profilers can not cleanly separate between stuff happening or being loaded in memory due to the play-mode player or due to the Editor. Therefore, profiling in the Editor is there for optimizing Editor scripts and behavior and for quick iteration, not for understanding and finding issues. For that you should always profile a built player, ideally on your target device.

Regarding your questions:
1. GUIViewHDRRT sounds like a RenderTexture used within the Unity Editor UI, so some Editor windows you might have open or inspectors. I'd be surprised if you'd see that when you profile a built player.
This is a good example for why profiling in the editor might mislead you to look at something that is a non-issue for your game. Similarly, "GameView RT" is the Game views output, "SceneView RT" the scene view's output, then there is some RT for the Camera Preview if you selected a camera in the sceneview... none of these will ever appear in your game.

2. I don't know enough about the Animation system to comment on this. Maybe you selected a model with animations and the inspector loaded the mesh and animations into memory (even if there might not be an inspector window open). You should be able to look at the animations reference count, click on it and follow the chain of references to see what is holding it in memory. The thing that loaded it might be gone by now and maybe the clips will be gone after the next "UnloadUnusedAssets"...

3. We have the list of references, which can help by showing what still keeps it in memory, and likely whoever created it is among those, but that is by no means guaranteed so, no there is no straight forward way just yet. We're looking at allowing to optionally store the call-stack for an allocation or similar means to improve on this. Besides that, we also want to providing a better way to presenting the reference chain ("Path-To-Root").

Does this answer your questions?

Also, thanks for trying the Memory Profiler and providing this input,

Martin

 

What Windows do you have open? timeline? Animation or Animator view?... maybe those cause it.
What do you get if you click their Reference count number what is holding these animations referenced?

 

Also, from what I heard it might very well just be expected behavior as your Animation Clips might be held in memory by their importer, so that they can be used. I.e. if you have an animation file with multiple sub clips in it as sub-assets, those sub-assets need to be created, so that they can be used in the editor.

It's similar to another question raised in this sub-forum about Sprites and the Sprite Atlas they are in, being both loaded in memory in the editor. For Editor purposes, both the bundled data and the separate data need to be in memory. If this for some reason becomes a problem for you, that might be something to raise as a bug so that the people working on these areas can see if memory load in the editor can't be reduced somehow.

 

No, I mean clicking on any item in that sub tree and then in the list underneath the tree view there is a Column named Ref Count with a number in blue that you click on to see the x number of things that reference this AnimationClip.

I guess you could close that window, reopen and capture again. It could still very much be the case that everything still is in memory due to the way the asset importer works but I have no special insight into that area, nor the importer for AnimationClips.