So, this is something I inflicted on myself. Was testing my game under low framerate conditions, made a script which sets max FPS to 10, forgot about it. Spend an hour figuring out why. As it turns out, when setting targetFramerate to low values, profiler starts displaying complete nonsense
It shows EditorLoop as a reason. Yet if I switch to edit mode, it doesn’t show anything.
I know it is my fault but maybe “EditorLoop” section should be elaborated upon a bit better?
I wonder what it shows with deep profiling (that elaborates a lot more)
I did enable deep profiler and that didn’t help. Might be me just missing something though
Note that it spends most of the time in Application.Idle … meaning it’s just waiting. This is likely the result of imposing an artificial delay on the framerate.
It is, made by me, which I, again, forgot about. Problem is that Idle takes 2ms not 90 and it isn’t clear that it is a result of setting target framerate, which only shows up as “EditorApplication”, only in play mode
Again, this is my fault. But UI could still be less misleading imo
That seems buggy. What happens if you switch the target to be the Editor instead of Playmode, which would then give you more info about the EditorLoop?
So that’s the fun part, it shows me like framerate is perfectly fine:
Right, that is definitely a bug. Could you please file a bug report via the Editor Menu Help > Report a Bug?
May I just send link to this forum without repro project?
Our QA would still need to be able to reproduce it and may need additional info like platform and hardware info but from your description a repro project would just need to set Application.targetFrameRate to 2?
That should be enough, yes
I can reproduce it with that. I’ll file it myself. thanks for flagging it
To clarify this a bit though:
What it shows during Playmode Profiling is correct. A target frame rate of 10 requires each frame to be 100ms long. Since the Editor is using a busy loop as part of the EditorLoop to spin while waiting for the targeted frame rate, that’s where the remaining 90-ish ms will end up in.
What’s wrong is that switching to Editor Profiling makes that whole thing disappear. There is something where switching target modes overrides the targeted FPS.
Oh and I’ve also logged the Feature Request from this thread.
Thanks!
FYI: You’re also always very welcome to enter your Profiler related feedback directly under https://portal.productboard.com/z8pw2ms6jxytyez9chlmm4kr/tabs/41-profiling → ‘Submit a new idea’ which will mean our Product Manager will go over it, sort it in with all the other feedback we have and we’ll inform our planning and road map accordingly.
FYI, you can track the Bug here
I’ve checked what is going on with profiler there and @MartinTilo is correct - the Playmode tick happens with the expected 100ms interval, however when Editor profiling is enabled it profiler treats every Editor update tick as a frame, so 100ms interval is spread across many frames there.
We’ve agreed that this behavior is not great for the playmode profiling as well as crosscomparing frames and going to align frames so that in Playmode profiler frame is equivalent to PlayerLoop update regardless Editor profiling state
