Resolved Why does initializing my objects take extremely long ever so often? [Unity 2022.3]

So I'm currently creating a game with procedural world generation. Therefore I am loading and unloading big chunks of world data quite often.

Step 1: Upon loading a chunk, it gets a thread worker which reads its data from a file in a seperate thread.
This worker also prepares "proto-objects" that contain most of the data that is necessary to instantiate my GameObjects later. This includes things like a Color array to set a texture and a Vector2 array to set a collider.

Step 2: Once the thread is done, it puts the finished proto-objects into a ConcurrentQueue where they are dequeued in the main thread and used to initialize the GameObjects. This includes adding the script and a SpriteRenderer as components and initializing a Texture2D with the createUninitialized flag set to true.

Step 3: The Creation of the collider as well as the application of the Color array to the texture and subsequent Apply() call are handled later (which works fine and is outside of the scope of this post)

Now heres the problem:
Step 2 usually takes about 0.5-5ms.


But every so often it spikes to taking 50-200ms.


As you can see, this happens in more or less regular intervals. I first suspected the garbage collector clears to have something to do with it because you can see it lining up with this spike here. This does not seem to be the case with the others though.
It seems to be texture size independent because in both cases highlighted here, the texture has a size of 160x160, which is the case most of the time.
Also just for clarification, theres only one object spawned in each screenshot.

Anyways, here's the code that gets profiled in the highlighted "Create Objects" part:

Code (CSharp):

1. public static PhixelObject Create(Chunk chunk, Vector3Int chunkPos, List<Vector2> verticies, List<Phixel> perimeterPhixels, Phixel[,] phixelMatrix, GameObject gameObject = null)
2. {
3.     //Create create
4.     PhixelObject phixelObject = Create<PhixelObject>(gameObject);
5.     //this just creates a new GameObject and adds the script as a component
6.  
7.     //Set Transform
8.     phixelObject.transform.localScale = new Vector3(Constants.PIXEL_PER_METER, Constants.PIXEL_PER_METER, 1);
9.     phixelObject.transform.parent = chunk.transform;
10.     phixelObject.transform.localPosition = new Vector3(chunkPos.x - Constants.CHUNK_SIZE / 2, chunkPos.y - Constants.CHUNK_SIZE / 2, -chunkPos.z);
11.  
12.     //Add Sprite Renderer
13.     phixelObject.textureRenderer = phixelObject.AddComponent<SpriteRenderer>();
14.  
15.     //"create Texture_x" + phixelObject.dims.x.ToString() + "_y"+ phixelObject.dims.y.ToString()
16.     phixelObject.tex = new Texture2D(phixelObject.dims.x, phixelObject.dims.y, TextureFormat.RGBA32, -1, false, true);
17.  
18.  
19.     return phixelObject;
20. }

(I replaced the manual Profile.BeginSample() calls with comments for readability and removed parts that are not profiled)

Well these spikes currently result in stutters that make the whole thing pretty unplayable, which means I've been searching for their cause for a few days now, not the most experienced game dev though so maybe you guys know something I don't

So thanks in advance for any help!

PS.: I put this in the graphics discussions because I thought the Texture2D might be the culprit, upon looking at it again though I'm not so sure about that anymore so feel free to move if thats possible

 

Well since nobody seems to have a clue, here are a few updates:

• I tried profiling in the editor, which resulted in the same lag spikes but this time categorized under Editor Loop:
  
  
• Since I can't get any more granular with manual profiler calls, I tried deep profiling which showed some weird results:
  
  
  First screenshot again being the usual/fast execution and the second screenshot being one of the lag spikes.
  
• I tried setting up a new project and creating a minimal reproducible example. But it turns out its more complicated then just instantiating the same object at the same rate.
  
• Both last points make me feel like its something going on in the background thats slowing down all kinds of unity internal stuff every once in a while.

I'm probably gonna implement some object pooling to avoid the whole issue completely. But whatevers going on in the background here won't stop I'm pretty sure so I'd be very interested if anyone has some ideas how to further debug this.

 

Alright so I've got a pretty smooth version running now but it took a lot of steps.

• First I implemented some object pooling to instantiate all my objects when starting the game. This made things better but I still had the occasional mysterious stutter as before.
• Next I tried reducing workload on the garbage collector further by reducing the size of my basic structs (which I have 80k per chunk of) from 44 to 20 bytes. This made things significantly smoother but still not what I wanted.

Finally I accepted that the texture.apply() call just takes a while longer every now and then and looked into how to optimize the amount of calls further.

A bit of background: The original reason for me to have lots of big objects with big overlapping textures per chunk was that I needed a fast way to hide the "z-layers" of each chunk, which I accomplished by spawning one object per z-layer and having my camera scroll through those layers. Think rimworld or dwarf fortress, something in that direction.

So an easy way to have less time spend on texture.apply() calls and instatiate less objects would be to just have one object per chunk, rendering one texture including all depth information that would be contained in the layers (like semi transparency for example).
I achieved that by:

1. Creating one render texture per chunk
   
2. Creating one plane per chunk and assigning the render texture to the plane
   
3. Write a ComputeShader that walks through the x-y-coordinates of each chunk and adds up z information, basically projecting the 3D data onto a 2D texture
4. Create a ComputeBuffer with SubUpdate mode
5. Use computeBuffer.BeginWrite() instead of .SetData, pass the returned NativeArray into a task to run it on another thread and avoid blocking
6. Important: SubUpdate ComputeBuffers do not work with the RWStructuredBuffer inside your compute shader, use StructuredBuffer instead and do not spend a whole day trying to figure out why your data doesn't arrive in your shader
7. Once the thread has copied the data, call the EndWrite(), then SetBuffer() on the shader and then Dispatch()

This way I not only solved the issue of spawning many objects per chunk, I also completely moved the expensive copying work that the texture.apply() call does to another thread.