koobas.hobune.stream
The question is answered, right answer was accepted
Above what overhead profiler percentage should I start worrying about it?
Hi,
Following the question on what Overhead stands for
I would like to know how then to read this value and when to start worrying about it and take actions.
For example,
I have a simple board game with 30 pieces to move around, my overhead if 5%, is that ok? This is the second item in my list coming up after the rendering that takes around 91%.
I have a full physics excavator simulation running 100 times more scripts, full GUI etc etc, and the overhead is only 0.4%. after render, physics and gui entries.
So I am a bit confused on how to read and analyze my scenes and where improvement can be made based on the overhead entry of the profiler.
Thanks for your insight!
Jean
Since this has come to the front page again.
Overhead represents time lost I the actual profiling process itself. There is little you can do to remove it. It will not be present in an actual build without the profiler.
Worry about the absolute time for all the other steps. If overhead is at 90% it means that profiling is using most of your time. Normally this means the rest of your game is running pretty well.
I was wondering why my game runs good without profiler on. Cheers
I may be very wrong on this but overhead seems to be inversely proportional to the complexity of a scene.
So, an almost empty scene should by all means have an overhead in the xx.xx range since you're having call overhead while rendering and computing basically nothing else and thus allocating very little.
A complex scene should see the overhead drop to x.xx because of a larger allocation for actual tasks and assets.
Overhead becomes increasingly important when your game is actually sluggish on your target specs. This is when I start to really optimize my code since less overhead impacts frame-rate heavily in this situation.
I don't think there is an actual overhead percentage that you should strive for. Just try to get it as low as possible.
Please vote this down and post another answer if I'm wrong, since I'm interested in this as well.
Very interesting azzogat, not marking it down to let others express themselves, but will do if it's quiet :) I also realize after doing more tests that the percentage might be also related to the framerate, that is with a very low framerate, the overhead is smaller than with a high framerate which was the case with my two examples, board game, very high fps, very high overhead, excavator big project, normal framerate, low overhead. It actually start to make some sense:)
Close your scene window while profiling your game. An open scene window seems to generate a lot of overhead.
public class SetTargetFrameRate : MonoBehaviour {
void Awake () {
Application.targetFrameRate = 60; // webplayer /PC/Linux /et cetera.
// Application.targetFrameRate = 30; // androidish / iOS, w/ev's;
}
}
//This helps somewhat. advising the app what you are aiming for.
//It would be trivial to conditionally include those calls based on build type.
