With latest C# we have a handful of new constructs to create more performant applications.
C# Challenge: allocation free algorithms
When talking 'allocation free' we mean heap allocations, while on the stack memory is still going to be allocated similarly as before.
I have been learning about F# and functional programming lately. There is a great F# site explaining the functional concepts fsharpforfunandprofit.
There are some really interesting concepts like Partial Application of Arguments and Currying. I wonder on how we could bring these concepts to C# and how the could would look like with the latestC# 7 syntax.
I will take an example which comes up over-and-over, and walk through this example, improving it each step in C#.
In this part I will take a look at a very simple solution, avoiding using extensions methods and Func types. My goal is not to provide a mathematically equivalent solution, but rather than to see how the new syntax to simplify.
In the previous post I have shown how value tuples differ from having multiple out parameters. The IL code has been shown and some micro-benchmarking have been done.In this post I would like re-visit one very interesting question around the performance and the generated IL Code. When we know for sure, that one of the parameters of a method is not needed, we can use a (int success, _) syntax to tell the C# compiler that we are only interested in the first parameter of the returned value tuple.
Here is the IL when we have both parameters used:
The previous post has shown that the average of deconstructing both parameters takes 18959 ms in that given test environment.
C# 7 has introduced lots of new features. One of them is the new ValueTuples
Instead of discussing the compiler syntax and usage of value tuples, I suggest to search on the web, here is one great post C# 7 Series, Part 1: Value Tuples about it.
In this post I will do a small micro-benchmarking and also look at IL Code got generated for multiple return types.I will use an example where I have a possibility to return two values, but previously we have used one result parameter and out parameter: a TryParse method. It is made up sample code though, probably you would never have this business logic in a real application.
In the previous post, I have investigated the performance implications of using the is and as keywords, including the new pattern matching syntax for the is keyword. Let me reference a previous work in this topic from Sasha Goldshtein, which motivated to do the investigation on the new pattern matching syntax of the is keyword: Micro-Benchmarking Done Wrong, And For The Wrong Reasons
In the previous post, I have measured performance with micro-benchmarking and took a look at the code, through ILSpy.
In this post I will take a look at the same code (invoking a non-inlined Work() method) but this time, I will use WinDBG and compare the native code generated by the JIT compiler.
JIT compiler's output may change with version updates of the framework, as this is an implementation detail to the CLR. The generated code also depends on the architecture of the system where we run our code. My test machine is x64 and uses RyuJIT compiler.
