After dabbling with F# and thinking about the code conventions and style that is idiomatic in that language, or at least in a FizzBuzz sample, it occurred to me that some of the ideals of F# could be seen as a potential code smell in C#.

Remembering this rather elegant looking snippet of F# from the previous post:

let fizzBuzzChecks n =
    None 
    |> fizz n 
    |> buzz n 
    |> Option.defaultValue (string n)

This pipelining of functions, and calling a function that has two parameters but only passing in one, is the type of F# I’m used to seeing in examples and has some very appealing qualities in terms of readability and maintainability, but something that always niggled at the back of my mind was “what about performance?”. Being a C# dev I thought of how partial application would be implemented in that language, and immediately the thought of lambdas and Funcs come to mind, perhaps something like this:

Func<int, Option<string>> fizzPartial(Option<string> result) => x => @is(3, "fizz", x, result);

This looks confusing, but you end up with a method fizzPartial that takes an option, and returns a function that takes an int. You would call it like this:

Option<string> result = fizzPartial(result)(n);

With this solution in mind I’ve always wondered then if the appeal of F# is that it can do these sorts of things without the normal performance or memory overhead that lambdas have in C#. Remember I’m a complete newbie to F# so I can only apologise if you’re yelling at your computer right now.

Lets measure!

If you have a performance question there is only one thing to do: measure.

I whipped up a quick BenchmarkDotNet project with my original F# from the previous post, and the C# equivalent. I deliberately did a straight port of the code, and didn’t rewrite it using Funcs as I felt that would be an unfair comparison. The code for the benchmark program is here on GitHub: https://github.com/davidwengier/FSharpVsCSharp

What I expected to see was the F# being a lot faster than the C# because my hypothesis was that it was designed to this sort of thing elegantly, but more importantly efficiently. The results were surprising:

Running the two algorithms for 10, 100, 1,000 and 10,000 elements each, you can clearly see that there is barely any difference in performance numbers, or memory used, and if anything the F# is slightly slower.

Strong opinions, weakly held

So my hypothesis was wrong: Excellent! That means I get to learn something. Hypothesis number two based on the results (ie, cheating) is then that the benefit of F# is that it is faster but since my C# code didn’t have the overhead of lambdas that it was actually a good sign that it even kept up.

That one is a bit harder to test with a benchmark though, so I pulled out the big guns and decided to have a look at how the F# compiler actually handles the code. To do this I went to one of my favourite tools: SharpLab.

SharpLab is an online code decompiler, and even has an experimental runner, and the reason I love it is that it specifically turns off all “syntax sugar” when decompiling so you can see what the compiler is really doing. I used it extensively in preparing for my talk on Lowering and in fact even submitted a PR for because it didn’t fully export the innards of using statements.

Feeding the F# code into SharpLab revealed the answer immediately! I used it to convert from F# to C# and the line for the above pipeline in F# looks like this:

FSharpOption<string> option = _.@is(5, "buzz", n, _.@is(3, "fizz", n, null));

The full decompilation can be see here on SharpLab

Ignoring the slight differences in naming and the underscores there are two things immediately apparent:

1. The compiler has inlined the fizz and buzz methods entirely which tells me that there are some quite aggressive optimizations in the compiler
2. There are no lambdas! In fact the pipeline has simply been flipped around with the result of the first function passed in as an argument to the second.

I’m very new at this

Clearly after seeing this code we wouldn’t expect to see major differences between the F# and C# since they are so similar. In fact further this reveals the harsh truth of my lack-of-F# skills: I didn’t use any partial application after all! Partial application would have resulted in the creation of new functions with less arguments, but there simply aren’t any. What I thought was partial application must have been merely the automatic passing of arguments through pipelines.

A helpful comment from Chris Carr set me straight though; I just had to drop the parameters from the fizz and buzz definitions.

let fizz = is 3 "fizz" 
let buzz = is 5 "buzz" 

With that simple change the code now uses partial application and the compiler will generate classes to hold those methods in a very similar way to how C# compiles lambdas. This can be verfied again with SharpLab but unless you’re used to reading lowered C# it can be confusing. Nevertheless with that change in place we can rerun the benchmark and the results get a lot clearer.

With the partial application in place we can see that the F# code is quite a bit slower and more memory hungry than the C#. Its fairly safe to assume that the overhead is simply due to needing extra classes - instances of which take up heap memory - and calling into those classes - with virtual calls being slower than the previous static calls.

So what did we learn?

So in summary it turns out that I still have a long way to go to understanding F#, but also that my gut reaction of “that must be using lambdas so it must be slow” is essentally correct.

Now in the real world this level of “slow” is unlikely to be felt but at least this exercise has confirmed for me that whatever the reasons for using F# are, performance is not necessarily one of them, at least not without the usual standard of effort that would be required in other languages.