Glad to hear it. The main problem I noticed the last time I used F# is that it generates more function calls, along with more heap references (vs stack-allocated structs) for things like boxed values, generators, etc to do simple tasks compared with C#. Is it the case that you can optimize all this out using parts of the language I don't know about?
F# supports value types just like C# does, so I wouldn't expect more boxing on the F# side. Some types like tuples that are used more in F# than in C# are reference types, so you might want to avoid them in your inner loops, but that generally just means writing F# that looks a bit more like C#. Likewise, as to the number of function calls, it's probably a question of style more than features, though you can do things like use the `inline` keyword to make sure that particular functions always get inlined at call sites, which can be a big win in some cases (it also allows you to write type-safe generic math code, which is an oft-lamented unsupported scenario in C#). Lots of people are making good use of F# in contexts where heavy computational requirements exist (e.g. finance or scientific computing), but I'm not too familiar with projects using it where more real-time requirements exist (though I think someone's in the midst of porting Quake III to F#, so it'll be interesting to see how that goes).