Performance spike while spawning actors after migrating project to UE 5.5

[Perfect_Human_Interface]

Edit: I updated the title to reflect that this seems to apply to spawning actors in general, see my post about testing below.

Hi, I updated my project from 5.3 to 5.5, and now I’m getting a significant and measurable performance spike while spawning bullets that did not happen in the previous version. I haven’t changed anything in the code. This wasn’t written to be performant, just to function for now, but it’s weird that it suddenly causes a problem when it didn’t before. I am spawning actors quite quickly, and the spikes seem to be the moment they are spawned. It doesn’t matter where I shoot or if they hit anything (into the air etc).

Bullet spawning code:

Bullet blueprint:

Stat graph showing bullet spawning spikes in 5.5:

Stat graph doing the same action in 5.3:

Does anyone know what could have changed either with the engine between 5.3 and 5.5 or otherwise in the process of migrating the project that could be causing this type of thing?

[nande]

@Perfect_Human_Interface

Does anyone know what could have changed either with the engine between 5.3 and 5.5 or otherwise in the process of migrating the project that could be causing this type of thing?

one important thing on 5.5 are PSO cache. but i wouldn’t expect that to impact like that.

there’s a lot that changed, i don’t have the answer for your specific case.
it might be a good time to implement a pool. i’ve made one and it’s on a free plugin if you want it.

JUtils/Source/JUtils/Actors/Pool.h at master

[Perfect_Human_Interface]

Thank you for sharing this! I am still new to UE and my programming skills are pretty rudimentary. I do understand the concept of pooling though and figured it would be something I needed to do eventually. Could you give me a brief explanation of how I could make use of this plugin? It is tangential to the question but I do appreciate it.

[nande]

welcome to the forums then.
don’t worry as a dev you’re always learning.
i’m happy it’s of use for you.

how to use:

• download the plugin

• copy to your Plugins folder

• enable the plugin (run your project find it on the Plugins window and enable)

• then on your player begin play or some place that runs when the game start

• • find the Pooler subsystem in your nodes. (Get pooler subsystem)
• • call SetPool (with the bullet class)

• then whenever you need a bullet call Pooler->Get (passing the bullet class)

• when the bullet needs to die, instead of calling DestroyActor call Pooler->Return(self) (self or this) (self or this must be the bullet instance)

basically. then you can play with the other settings and parameters.

The pool will call SetActorHiddenInGame when you get a bullet and when you return it.
The pool will also call Reset on the bullet when you get one. So a trick is to override the “Reset” function in the bullet and reset values there.

[Rev0verDrive]

You can do your own pooling. Pool projectiles shouldn’t be replicated, therefore you’ll need multiple projectile classes. Each proxy will have a custom projectile class that handles very specific actions. For example client pools apply local hit fx, where as servers do not and they calc/apply dmg.

Dynamically setting Projectile Movement Component from Game State variable

First up projectiles in multiplayer should not be replicated. You have each Proxy of the shooter do their own thing. Server should only replicate relevant data. Keep the network footprint as low as possible. Client fires its own local projectile. Simple hit detection, A/V FX etc. RPC the server to shoot. Server determines its own values and fires it for authority. Dmg hit detection etc. Multicast to SIM proxies passing the servers values. Sims fire the shot, A/V FX On Server hit, Multicast the…

[Perfect_Human_Interface]

I decided to do some more testing.

I created a test actor that simply spawns an arbitrary count of another test actor, repeating on a loop. The spawned actor has no components and the only code is that it destroys itself after a short time. From this I seem to have learned two things:

1. In Unreal 5.5 it does seem to cost slightly more simply to spawn an actor than in 5.3. The difference doesn’t appear to be a lot (for otherwise empty actors), but it’s there. Testing in PIE and in standalone, generating varying amounts of actors (from 1 to multiple hundreds at once) the spikes seem to be hitting consistently higher in 5.5.

2. For whatever reason, running the game in-editor from the main (default layout) level tab, even in a new window, exacerbates the frametime spikes caused by spawning actors. This is actually how I usually get the best overall performance for PIE at least, but the spawning spikes are the worst in this play scenario.

The combination of these two factors meant that in a practical case (running my game normally in PIE) I was getting visually noticeable spikes where I wasn’t before, even spawning just 1 actor at a time.

That’s a bit weird isn’t it?

[nande]

i think you know this, but just in case.
it’s completely normal and understandable that in editor it will run with less performance. since it has a lot more overhead and even data. that’s why usually it’s recommended to do your performance tests on packaged builds.
as for 1. i havent noticed, but it might be possible.
the only alternative i can think of is to work around it. or spend some time to narrow down the extra cost.
maybe using “insight.”
though i think the architecture changed a bit in 5.5. they’ve changed some fundamental code.

though, in general, spawning actors frequently it’s not really something that is recommended.