FSharp.Core not optimized?

Question

Hello,
I've recently inspected the performance of a F# app and while digging through the CIL I've found out that FSharp.Core (for .NET v4.0) contains several nop instructions, many unused variables and variables which are only written/read once via sequences of stloc/ldloc instructions.
I've investigated the possible causes and I've noticed that even in release mode F# assemblies include the --debug:pdbonly directive and there's no way to disable this and switch to --debug- from the project settings UI.
I'm wondering if there was a specific choice for the compilation settings of FSharp.Core and if so what was that. Otherwise is it legitimate to expect a fully optimized version of the runtime?

Answer 1

It seems like the comments on the question have already answered about 90% of this; to reiterate them:

• nearly every release binary in the universe is compiled with --debug:pdbonly
• even if the IL code is sub-optimal, this may not have any real-world impact due to the JIT optimizing it away

There are, of course, all kinds of ways the F# compiler could be potentially emitting better code (this is probably true of every compiler); if you profile your app and notice something bad (e.g. a big discrepancy versus comparable code from C#) then you can let the F# team know by mailing fsbugs. But measure first.

Answer 2

Otherwise is it legitimate to expect a fully optimized version of the runtime?

The changes you suggest cannot reasonably be regarded as optimizations. Both are harmless and will be compiled away by the VM. ISTR, mutation is used to replace stacking because the stack-based VM can stack overflow. So that is F# correctly working around a bug in the CLR.