I tried to profile my game and at the moment Im a bit confused about whick values to trust.
The stats window in my game view reports 140fps. Time.deltaTime is somewhere around 0.02 on average, which would mean 50fps. The profiler reports a few spikes (GC etc.), but on average the frame rate reported by the profiler should be around 1000fps.
So which one should I trust, and why do I get all those different reports?
This is an interesting question and I wish I had the definitive answer as to which to trust, but the truth is that none of them is 100% correct.
The stats window is likely closest for something like fps, but it's quite hard to say. Time.deltaTime should be the most accurate, but the overhead of writing out the values changes the results. The profiler's estimate for fps is too generous.
One of the reasons that you get three different values has to do with where the values are coming from, especially if all three are happening simultaneously. Bear in mind that all of these stats are running in the editor which also incurs some overhead that the stats window and profiler will try to accomodate for.
The stats window is a rough approximation of what's really happening in the game view to try and give you an idea of what the run-time performance of the scene is going to be at, but you shouldn't trust it as definitive because it is often wrong (try working out the draw calls for example).
Time.deltaTime is giving you representative values of what is actually happening. This is accurate, but since you are running in the editor, this value is likely less than Unity predicts your run-time to be. Moreover, if you only write to the log for this test case as opposed to writing it for all three, it would even further offset the values as writing to the log is apparently not cheap (I've actually been able to pretty much freeze Unity with some for loops that just write to the log).
The profiler is going to try and guesstimate what it thinks your final run-time fps will be at. This is very off because simply running the profiler eats a lot of memory in and of itself, affecting the results so it must predict to a fair degree. For things other than fps, the profiler should be fairly accurate.
I know this is an old question, but answer to this question can be found in this thread:
https://forum.unity3d.com/threads/is-unity-fps-count-wrong-or-am-i-missing-something.150139/
Rene Damm from Unity Technologies:
Hey guys, let me try to shed some
light on what’s behind the Stats
window
…
The key issue here is an architectural
one: when playing in the editor, the
editor and the game use the same
single engine/runtime. Which means
they run their stuff together and
batch their stuff together to the GPU.
…
Hopefully, this makes sense now. If,
conceptually, GameUpdate() and
GameRender() take hardly any time at
all, you will see the Stats window
report crazy high FPS. The fact that
the actual effective FPS (as measured
by the FPS counter script) is so much
lower is because there’s still the
editor which does its thing and takes
time.Note, however, that in this case the
“Stats” window is actually more
correct than the effective FPS
measured with a counter script –
because if run standalone, that game
would indeed have high FPS counts.
The stats window tells you how long it takes to draw the graphics. This is only sort of related to how fast your game actually runs in terms of frames per second, because it's totally ignoring everything else. It's not a matter of "which is more accurate" than the profiler, since it's two quite different pieces of information altogether.
In any case, the editor has a lot of overhead that's not present when running a build on its own, so for truly accurate fps info, you should use this script in an actual build.