GC.alloc called 8 million times

Hi,
Could you maybe deep profile this?

I'm assuming EventManager.SaveWorldEvent is just declared as

Code (CSharp):

1. class EventManager
2. {
3.     public static DelegatType SaveWorldEvent;
4. }

and not as

Code (CSharp):

1. class EventManager
2. {
3.    
4.     private static DelegatType saveWorldEvent
5.     public static DelegatType SaveWorldEvent
6.     {
7.         add
8.         {
9.             //Some crazy logic here
10.             saveWorldEvent+= value;
11.         }
12.         remove
13.         {
14.             saveWorldEvent -= value;
15.         }
16.     }
17. }

Registering an event does cause some allocations, as simply but, it is added to a list and that list might need to grow (there is some wrapping and joining happening as well iirc but the jist of it is, it allocates enough that I once implemented my own even lists so I could allocate the list once and registering and deregistering came allocation free)
Now, registering one object, shouldn't cause this many allocations.

If you have 8700740 DefaultObjectSaver MonoBehaviours (or anything inheriting from it) or nearly that number, then you've found the root of the problem. If the event list becomes this long, the list will grow like crazy and every growth is a reallocation and the memory has to be moved. (Also the above mentioned joining that is happening in events doesn't scale so nicely.)

It could also be, that you're looking at the event being fired. When you assign a Method like that, it can happen that it will be automatically wrapped by the delegate type. When you debug, you could observe the event calling to first step into your Start method and then into your SaveFunction. It is therefore conceivable, that the Start() sample was somehow picked up in the wrapping delegate.

 

To find out, if it is, what I described in the last paragraph, you could use deep profiling or use one or more CustomSamplers in your SaveFunction
https://docs.unity3d.com/ScriptReference/Profiling.CustomSampler.html

 

When deep profiling, can you use the searchbar to search for your Start method, the save function, GC.Alloc and the event? If any of those are still present but just somewhere else, please take a screenshot of that (ideally with the searched cleared) and post it here. You could also save out your profiling data with the save button so I can have a look. You can PM me if you don't want or are not allowed to post this file publicly. (Not sure how much one could read out of that file but who knows, maybe there are some telling method names )

 

Have you tried placing a CustomSampler with begin() and end() in your start and a different one in your SaveFunction? With these, you should be able to search for them and scrub over the frames to find it.

Regarding the filesize: yes, it's a lot of data and the reason why we only store up to 300 frames. You could clear the profiling data before the moment that triggers the Start() and pause right after, then save. That should trim the file size a bit. Additionally, the files can be compressed rather well, so you could zip or 7zip it.

 

Hi,
Sorry for the delayed reply.

So the issue here is with the way c# events work. They are multicast delegates and every time you add another listener, it throws it into the mix which produces GC.Allocs that get worse the more listeners there are. One solution is to write an EventList class where you subscribe your delegates in a list of listeners that you manage yourself. Then you can just preallocate that list to a reasonable size to avoid costly resizes as you add listeners.

The reason you can't see the sample in deep profiling is because the frame it would show up in is so heavy, that the profiler runs out of buffer space while collecting samples for it. We're in the process of fixing this though.

I can't reproduce the .Start() sample appearing underneath a coroutine sample, though. Are you loading a scene/ instantiating the objects from within a coroutine?

What Unity version are you using? I'm assuming 2017.x?

@Whatever560 you're issue is likely unrelated so it'd be good if you can share the code of those coroutines.