I once decompiled a Windows Microsoft DLL imported function, and it clearly had a lot of optimisations such as quitting if the 1st character is 'n', etc.
I believe some places have very tightly optimized code. What I question is the risky assumption that under every .NET class you have carefully optimized code, refined for over 30 years. What did I use 30 years ago? Oh... A 6502. I had an Apple II+.
I also believe the Java stack has some very carefully optimized code too. It certainly has the performance to back up that affirmation. Besides that, it was designed to be easily portable to other OSs and architectures, a feature that's more important, IMHO, than speed under Windows.
Finally, you should only optimize for speed the code your profiler says has big impact on your performance. The rest you should optimize for readability and correctness. There is a lot of very subtle bugs we introduce when trying to optimize stuff and it's much easier to optimize correct code than to fix blazingly fast, heavily optimized buggy code.
I admit I was way off - Windows has only been around since 1985 or so, and in usable form since 1990. And Java does have some very fast code. And I agree about optimisations too. It's easy to go overboard to get more speed.
I was doing hand-optimizing of 6502 on the Apple ][+ back then. Well, a little bit, admittedly. The thing to do seemed to be a mix of BASIC and machine language. CALL-151 for the win!
You know it's not more a compliment to .NET than a harsh critique on the (utterly detestable) Win32 API.
> Whereas Java has underlying it more Java, .NET has underlying it 30 years of carefully-optimised Windows C/C++ code
Your faith in humanity impresses me.