Excessive slowdown with lots of sprites

[Chris]

At least, I'm assuming it's due to a lot of sprites, given what I'm seeing. With the Metroid Dreadnought mod (link is for the more-recently-updated overhaul, though the same thing would happen with the original), the charged and missile-enhanced wavebeam shots create a lot of particle effects, which tank performance for me. I'm talking multiple seconds-per-frame in the worst case, and can last 10+ seconds real-time. I see similar slowdown with the powerbomb, although it doesn't last as long.

Here's a screenshot showing a normal frame:


And here's a frame in the midst of the issue (getting about 0.5 to 1 FPS):


CPU:
Athlon64 X2 4200+ @ 2.2GHz (dual-core)
GFX:
GL_VENDOR: NVIDIA Corporation
GL_RENDERER: GeForce GTX 650/PCIe/SSE2
GL_VERSION: 4.5.0 NVIDIA 384.130 (Core profile)
GL_SHADING_LANGUAGE_VERSION: 4.50 NVIDIA

Screenshots were made with the OpenGL renderer, 1280x720 windowed, 2x overscaling, although it also happens with the software renderers without overscaling too. Tried with a fresh ini, no change. Tried turning off dynamic lights, no significant change.

Interestingly, when I first tried out the mod some years ago, the slowdown was very minor. Over time the slowdown got worse, and it's been like this recently. I recognize my CPU is quite old and is the likely culprit (I've not heard of performance complaints from others using the mod), though the slowdown still seems rather excessive even considering that. Assuming there's no improvements to make on the engine's side to help this case, are there any cvars that may be able to keep it from getting so bad?

[Graf Zahl]

Sprites are not cheap to render, as you can clearly see in your numbers. I really cannot imagine that this ever worked well.
The time is split across 3 items:

Think time, where most is spent in script code, preparation time for rendering and actual rendering.
My guess is that this particular mod got hit badly by the scripting VM, because this is where it spends the majority of its time.
But regardless of that, this clearly shows a lack of care towards performance-conscious design. You cannot have 5000 sprites and expect it to work without performance issues. Of all the items in the game, sprites are the most costly ones to set up.

[Valken]

I noticed excessive sprites would slowdown GZDOOM as well and was wondering if splitting the VM out as a separate game thread to use another CPU core would work and improve performance? Like a blitter from the old consoles such as NEOGEO? That was massive sprite machine and maybe it would help performance on a modern system?

[Graf Zahl]

It's not that easy. Much of the game depends on serial execution and for the vast majority of mods this really is not an issue. Adding a second thread here would also cause other problems and may even slow things down in more common scenarios.

[Nash]

For use cases like this (visual FX), the extremely bloated Actor really isn't the best tool for the job.

Particles with custom sprites would be a much better solution.

[Graf Zahl]

The main problem here is not the size of an Actor object. Most of the time is lost in complex DECORATE stuff where particles wouldn't help.

[R4L]

If you look at the code for that charge combo, you'll see why lol. It's been that way since it first released, way before I got my hands on it.

I'm working on nerfing it, which should help with frame rate. On my rig I get slowdown, although not as bad, and I'm using a i5-3570k. I do know it's there though, and I'm pretty sure nerfing it would fix it.