ParticleSystem.Update using significant resources even for default particle system

It is not that I am misunderstanding that this could be difficult. What I am pointing out is that this is LTS. That means people choose LTS because it is meant to be supported long term. It means that projects will be started and ended with this particular branch because it is LTS. Now, given that, if a known issue is decided to be not fixed because it is hard and it has risks....well then it beats the whole purpose of the LTS. I might as well as use the 2019 Alpha, I mean seriously is there a real difference if known issues are to be handled this way? Why claim long term support when the issues that require long term support will not be worked on?

This is just ridiculous.

 

@richardkettlewell
Hi Richard, is this particlesystem update issue fixed in 2018.3? I'm confused by the tracker page https://issuetracker.unity3d.com/is...op-after-upgrading-from-5-dot-6-to-2017-dot-1 which states "Fixed in Unity 2017.3.0f3" and your responses to jjejj87, basically saying it wouldn't be fixed for 2017.4, and only to be fixed in 2018.3?
I'm currently getting a lot of slowdown(the profiler shows WaitForJobGroupID as the culprit) with several particle systems(with admittedly large quantities of particles each) in 2018.3.0f2 and it appears to be similar to what has been described in this thread by everyone else, but I don't know if this is a just pushing the limits of the system or if this is a continuation of that(is WaitForJobGroup the same as WaitForJobGroupID?) issue.

 

I am still getting this WaitForPreviousRendering lag (upto 100ms) and I am on 2018.3.12f.
However, I only get hit if using MultiThreaded rendering, without MultiThreaded rendering the lag is not there and (consequently) performance is much better.
I dont think this issue is fully resolved.

 

I'm trying to get to the bottom of performance issues and noticed particles taking almost 3ms of my frame time whilst "WaitForJobGroupID" which lead me to stumble across this thread.

Frankly, this all feels like a mess even in 2021 LTS. My main issue here is clarity so I will explain my situation.

I know I am GPU bound so I've been spending time analysing builds in RenderDoc and optimising the biggest offenders. However before I take on a task of optimising the draw calls I make a point of disabling the drawing of things as a quick win to see what the result of the optimisation could be. I start disabling things until barely anything is drawing and I'm still not hitting 60FPS consistently.

Hmm.. must be CPU bound as well, back to the profiler. I first check the editor since builds take me at least 5 mins and since I'm testing performance, and the profiler takes a lot of CPU time, I make release builds for a more accurate test. Meaning I can't just target the build with the profiler without making a new one.

What doesn't help is seeing a big whack of time spent on particles each time I look at the profiler. There is no way for me to know from the profiler alone that actually, did I make a change to particles? I have to go and disable all particle systems to confirm that no change is registered.

Plus I now I have to make a new build to see if I see the spike outside the editor, which means I also have to make tools to disable particles at runtime to test the changes.

I shouldn't have to do this. This is Horrible for clarity. What I want to see is like when profiling builds and just an overall spike for Gfx.waitForPresent or something like that because without it this cost is incredibly misleading. It also makes the particle module of the profiler almost pointless. What if I turn on a really expensive particle system, is it suddenly going to be half the cost of waiting for a job? If so when i first turn it on it will appear to cost nothing. Only way for me to know is to disable rendering and look for the change and I should not have to do that. When profiling what I need is accurate information that leaves no room for doubt.

I think, from a profiling perspective this setup is fundamentally flawed. I don't think there is a name you can give this sample without it being misleading. E.G "Wait for last present" would lead my first thought to be that particles specifically took a long time to render last frame, which seems not to be the case.

Overall the system itself feels flawed. Yes the spike will move but if I have no particles in a project the particle systems manager shouldn't be stalling the main thread waiting for a render to finish. Surely this should instead be handled by some sort of frame timing manager instead.

I've lost track of how many times I've got confused by this spike and wasted time disabling particles before having to search online for what is going on