In the previous post, I have shown why the following type can be dangerous:
ConcurrentDictionary<string, List<int>>
The problem starts when we have multiple threads using (writing and reading) this dictionary at the same time. To avoid state corruption, we need to control this access by making it thread-safe.
One of the rare situations, I face is having a dictionary of key-value pairs, where the values are a collection of some items. One example could be the following dictionary, where the keys are strings, and the values are a list of integers.
ConcurrentDictionary<string, List<int>>
In the series of this and the following posts, I will investigate how these collections can be made thread-safe.
I have come across this question several times, I thought it might worth a little investigation. Which of the following method runs faster TestAsync or TestDirect, given the Sum method?
public async Task<int> TestAsync(int a, int b) => await Sum(a, b); public Task<int> TestDirect(int a, int b) => Sum(a, b); public Task<int> Sum(int a, int b) => Task.FromResult(a + b);
At first look there is not much difference, but if we look at the performance of them, one executes faster.
At second look we could assume TestDirect must be faster as the compiler 'probably' does not convert it to a state machine. Or is the compiler smart enough to optimize away the state machine in case of TestAsync?
In this post I will take the existing methods to a higher abstraction by handling them as pure C# Func.
First we need to introduce a couple of extension methods, which will help to Curry and Partially apply some of the arguments on the existing methods. In C# this is a slightly more difficult, because we would need to create overrides for each different signature based on the arity of the method.
Creating an extension method for Currying:
public static Func<TIn, Func<TOut>> C<TIn, TOut>(this Func<TIn, TOut> f) => x => () => f(x); public static Func<TIn1, Func<TIn2, TOut>> C<TIn1, TIn2, TOut>(this Func<TIn1, TIn2, TOut> f) => x => y => f(x, y); // Further overloads
I have seen a Pluralsight course recently on performance by Sasha Goldstein. At one point, he mentioned how he had used processor pipelining to find a maximum number of an array of integers even faster the than the regular for/while loop. This got me thinking, can we get the presented solution even faster? (the catch: he also presented some other features of the clr/framework which will help with this)
So how can get even faster (in certain situations) finding a maximum integer in an unordered array?
In this investigation, I am going to use micro-benchmarking, which is certainly a way of measuring one or a couple of instructions, but I find the results difficult to generalize: things being measured are correct, but small changes to the code or the environment can have significant impact on the results.
In my tests I will use an array of 2MB, which easily fits into the processor cache of my machine. The array is filled with integers [0..10000). It is important to have it the whole array fit in the processor cache, so we can avoid measuring the latency for bringing a chunk of data from memory to the processor.
