Slow Instantiation of First Objects only on IOS

[Ebonicus]

Hello,

I am on PC/Win 10 Unity 2017.4.301f, and for Android builds
Apple for XCode building.

I have been having an issue with a noticable lag on instantiating objects for the first time, but now it is only on IOS.

I have read all of the threads, including this one which helped a lot:

first time object instantiation is slow

Hi I have noticed that the first time I instantiate a 3D object or a GUI Texture its slow. This gives the first-impression a game is slow to load and stutters/pauses as it goes along whilst on 2nd play, things are much smoother. I am posting this as I thought I would see if there is a solution to this problem before I release my game. I have a simple first iphone game with 16 cubes that get instantiated one after the other. When you first play the game, there is a pause of about 2 seconds whil…

I am already pooling the objects in an infinite scroller,
and have over 100 types of obstacles so I do not want to put a copy in scene and delete, or preload,
as these are fairly detailed textures on low poly models.
Read/write is disabled on all model fbx’s as there are very few with rigs or animations.

I have pinpointed the issue to textures, and am using all power of 2 compressed.
But the first time instantiating issue is evident in IOS platform in the editor, and on the IOS devices as well.

There are zero instantiating lags on android, even old android devices.
Even on a powerful PC, when the unity editor is in IOS mode, the instantiation lag is present.

I know for audio Android prefers wave/ogg and Apple prefers mp3,
and there are considerable performance differences.

I am thinking there is something in the asset import meta that I might have missed.
So here is my question, is there a preferred, optimized texture image file
format and compression method that IOS handles better than others?

Your time and assistance would be most appreciated if anyone has tips, thanks!

[Ebonicus]

Update:

I have tried a preloader scene, which instantiates all items ( and disables them)
Then checks if they exist in heirarchy prior to deleting.

The issue still is occuring on IOS.
Main scene stutters when loading item for the first time.
No stuttering appears when they are instantiated a 2nd or or 3rd time.

I will try moving preloader to the actual scene where they are spawned normally.

[Johannski]

Is the stuttering occuring even when the instantiated objects are not seen by the camera? Might be the texture upload to the GPU or shader compiling otherwise.

[Ebonicus]

@Johannski

Is the stuttering occuring even when the instantiated objects are not seen by the camera? Might be the texture upload to the GPU or shader compiling otherwise.

Not sure what you mean, but I have tried this:

Preloading and deleting all the items ( not in camera view, blocked by a loading canvas)
The stuttering still occurs
Preloading in camera view ( in game) and deleting the item results in the item never stuttering again on future instantiations.

Are you suggesting that if I preload out of camera view, the GPU texture upload and/or shader compling does not occur?
If that is the case, how do I preload in a manner that forces GPU texture upload or shader compling?

[Johannski]

@Ebonicus

Not sure what you mean, but I have tried this:

Preloading and deleting all the items ( not in camera view, blocked by a loading canvas)
The stuttering still occurs
Preloading in camera view ( in game) and deleting the item results in the item never stuttering again on future instantiations.

Are you suggesting that if I preload out of camera view, the GPU texture upload and/or shader compling does not occur?
If that is the case, how do I preload in a manner that forces GPU texture upload or shader compling?

Yes, that is the case. If the object does not get rendered the shader won’t compile and the textures won’t be uploaded to GPU memory, this all happens when needed. For shader Compilation there is a thing called ShaderVariantCollection which supports prewarming them (WarmUp). This however is sadly not too reliable. I would suggest just showing the objects to a camera that won’t render to the screen.

Since your problem seems to also occur when just instantiating: I did a lot of instantiation for an endless runner project of mine and had no problems with instantiation itself, I don’t think that will be your specific bottleneck. Maybe you have scripts that create garbage in the awake/start method and therefore trigger the Garbage Collector and the effect is less visible later on when the heap has already grown a lot? Did you profile on the device with the unity profiler? If so, did you see any spikes there?

[Ebonicus]

@Johannski

Maybe you have scripts that create garbage in the awake/start method and therefore trigger the Garbage Collector and the effect is less visible later on when the heap has already grown a lot? Did you profile on the device with the unity profiler? If so, did you see any spikes there?

This is an infinite runner, with 100 unique obstacles, only 5-7 onscreen at a time.
Obstacles have no awake/start/update code

Yes, profiler shows spikes for 2 obstacle features:
obstacles using a standard (non mobile) shader, required
objects using a particle system with mesh (not billboard)
What is interesting, is this is purely IOS only.
Both unity editor in IOS mode, and the ios devices from iPhone 6 thru X,
get this lag spike causing a perceptible screen.

Android has no instantiation issues, or spikes in profiler.

Once an obstacle has been spawned (on screen) once, it never happens again, unless editor is restarted, or IOS device is rebooted ( or all memory used by other apps and overwritten). So both IOS and unity editor are caching the object/materials somehow. Could this be something only in Metal?

[Johannski]

This sounds a lot like shader compiling (See Shader.CreateGPUProgram takes a long time on first startup (iOS) ).

When you take a look at the profiler to see what exactly causes the spike, do you see “Shader.CreateGPUProgram”?

A screenshot of the attached profiler to your iOS device with a complete hierarchy foldout of the profiler frame which shows the spike would be helpful to understand the cause better.