Trying to track down performance issues
Options
In the absence of instructions, I've just started doing StateManager.AddTracking() to every unity component with gameplay dependent state. (about 20-25 classes, averaging 4-5 variables each, with 3-4 classes having long lists/arrays of values)
However, I am now getting horrible performance issues that are nigh impossible to track:
http://imgur.com/Qv8r0Gl
Now obviously, these are a result of misuse, but I am not sure how to take these profiler results (Which complain about physics problems) and turn them into solutions.
However, I am now getting horrible performance issues that are nigh impossible to track:
http://imgur.com/Qv8r0Gl
Now obviously, these are a result of misuse, but I am not sure how to take these profiler results (Which complain about physics problems) and turn them into solutions.
0
Comments
-
Hey @Xelnath, how many TS colliders do you have in the scene?0
-
About 20?0
-
The problem seems to occur when two 'hard' (non sensor) bodies intersect. The engine somehow goes into a horrible loop. I've been working with the Unity Engine.Profiling.Profiler tool to try to track down where the performance goes all weekend.... to no luck.
I am not even sure why the bodies suddenly started intersecting. Colliders would just hard stop before. Now they won't.0 -
-
Here's a video of the problem in progress. Things are fine, then two physics bodies get shoved up against each other (knight jumps on grey dude) and everything goes to crap:
https://slack-files.com/T08T0G6EN-F69E9UJ65-73277f75d6
0 -
(P.S. Could you guys add image upload support to your forum? It would make image hosting much easier.)
0 -
https://i.imgur.com/IIy14Is.png Here's an example of the colliders intersecting.... I know this is a mess to explain.
Here's a simplified one with the sensors turned off:
https://i.imgur.com/k8qnkNb.png
You can see the 'square' body of the Orange guy is intersecting the yellow collision box for the grey guy0 -
More info. I've thrown away most of the TSTransform, etc, code, choosing to directly manage the Shape objects directly. Seems okay, but sometimes the engine goes bananas:
https://i.imgur.com/uWV9JWy.png
This is from a scene that consisted entirely of static colliders, 1 dynamic Shape with 8 'sensors' around it.
Cyan = Dynamic shapes. Yellow = sensors
First time I ran it - great! no problems that weren't outside of gameplay code. Unity then crashed. I closed and reopened it - and now any time the 'sphere' is touching the ground, I drop from 99 fps to 2.5 fps...
0 -
More interesting 'under the hood' performance analysis:
Note the Memory usage (9 megs?!? per frame!!)
Now note the block of code invoking it:
This doesn't even make sense...
However, this is a fun bit of information: c._toiCount > Settings.MaxSubSteps is getting called a HUGE number of times...
Over 450 times in fact...0 -
Toggling #define OPTIMIZE_TOI for kicks ends up revealing that the variable name 'Sweep' was changed to _sweep and not updated in the code.0
-
Jackpot.... turns out the timing of when you set 'IsSensor' is very important - if you do it before the fixtures (shapes) attached to your rigidbodies are created, it will cause your Kinematic bodies to trigger infinite collision solves per frame.
Causes infinite agony on your CPU.
Works perfectly.
1 -
Woww, wonderful finding @Xelnath!! Did you face the problem again after your changes were applied?0
-
Yeah, I ran into the problem again whenever two 'units' touched. Performance takes a nose dive, but only drops to 20 fps instead of 5 fps.
Still looking into it.
Sadly, enabling #define TOI_OPTIMIZATION leads to my units falling through *all* geometry in the game which indicates to me that code is unfinished.
0 -
Current results from my profiler... really struggling to track down where these memory allocations are occurring...0 -
Odd, why does this invoke a 1.2kb memory allocation?
This seems odd... all it does is ask for unity components. Perhaps this is so expensive a request that it should be done in a lazy way (don't request it from unity unless the event handler requests it)0 -
Humm, did you find that allocation in other unity component requests?0
-
Looking at it, all of the other unity calls are cached and done once at component creation time - such that only single references are done later one. This one is unique in calling GetComponent() at such a critical venture... though why its called so many times, I know not.0
