CPU being choked by GC.MarkDependencies

Never heard of GC.$$anonymous$$arkDependencies.. didn't even find it in the System.GC class. (I even peeked inside the decomplied mscorlib.)

Nevertheless, it sounds as if the actual creation of the objects causes the spike, so my first attempt would be to figure out a way to create as few objects on the heap as possible.

What does the code look like?

Yeah, I was surprised that $$anonymous$$arkDependencies didn't get any hits at all in Google. I know what it's doing in theory but it seems odd that it has to take the processor for that long.

I'm not sure about all the code since I'm very new to it but the gist of it is that the previous player and all of their many, many subobjects are despawned and a new one is immediately created. I'm sure that's the root of the problem but I'm not sure why the marking process should take so long.

Are the Player's (sub)objects the same or at least similar? $$anonymous$$aybe you could make a Set method that takes in a new Player(sub)Object and ins$$anonymous$$d of destroying the old one, copies the values. Like e.g. Vector3 and Rect have.

Yes, something like that needs to happen in the long run. What's happening now is pretty inefficient. Right now I'm looking to see if there's a quick fix that can alleviate the hitch we're seeing and try to understand what's making $$anonymous$$arkDependencies take several seconds.

I'd need to see some code to be able to tell you anything more.