Looking at the Application.ProcessWindowsMessage profile entry:
The sum of its children does not match its total “Time ms” cost. It shows 15.78ms, but the children sum up to 5.53ms (3.62+1.69+0.19+0.03).
There are 10.25ms “missing” in the profiler, which is significant. Perhaps you want to improve that marker, which might allow us to more accurately report editor performance issues.
Hi!
Note the “Self ms” column next to “Time ms” - this is the time spent inside this particular marker.
For “Application.ProcessWindowsMessage” it’s 10.23, which is very close to what you’re missing there 
Thanks for your answer.
Do you think it would be insightful to show what parts inside Application.ProcessWindowsMessage spend about 20% of the EditorLoop performance?
Idk, it depends on what’s inside
Hi Peter,
I’ve been looking into this a little bit. It appears to me as though most of that self time is spend in Windows APIs to actually get those messages. Still pondering if and how to clarify that via markers…
Really cool, thanks Martin! Looking forward to find out where all those ms are being spent and if we (and with we I really mean you (plural) ;)) can chop off some of it.
Not sure we can do anything there, this is Windows (as in the OS) spending time in it’s APIs when we are looking through the message queue. Caveat: I’m not knowledgeable about the Windows platform code so I can’t really make any definitiv conclusions here.
You can hook up PIX to the editor to get more details though.
My hope was the 10ms aren’t spread evenly across the entire method, but hopefully just a few code paths in that function that cause the most cost.
And once those have been identified, new ideas usually arise how and if it’s possible to optimize that code.
But first we need to understand where and why, then we can act and find the how.
I can be totally wrong of course, it’s just my approach to these type of problems, so I’m thinking out loud. 
EDIT: I’m know, you’re the experts and I’m not. I’m just trying to spread some ideas here, which hopefully lead to a better Unity experience for me in terms of performance. I’m not trying to hurt your pride in any way.
Are you saying that Windows is using 10ms to process a single message?
That miiiight be you doing something no quite right when calling those API’s. That sounds like way too much.
No, it’s not a single message in there. The profiler shows data for a single frame, and it processes multiple messages.
From the code it looks like it’s just doing the regular “Translate + Dispatch” WinAPI calls.
Well, in the provided screenshot there are at least 6 events being processed and each event (some may not show up here) has some self time that is not currently captured by a dedicated Profiler marker. That said, in a test where this thing took way longer (I was button mashing to get it to spike, not sure what exactly I did) I did indeed get a single message taking somewhere south of 8 ms (one instance in like >600 frames). I wouldn’t presume to be able to make an educated guess if this is something on our side or on rhe Windows API or whatever might interfere with that? I have no clue about that code.
