In the previous post, I have shown why the following type can be dangerous:
ConcurrentDictionary<string, List>
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.
I have doing performance tests in regular Console apps and BenchmarkDotNet for a while. Recently I have been seeing people doing the same from unit tests. At first it seems to have many advantages to run a unit test to measure how long a certain peace of code runs.
Certain things I noted immediately:
The time to run a unit tests != the time your peace of code runs
It is a lot more difficult to measure only a certain portion of an algorithm, you will likely to include measuring test initializers
Running along with a test framework brings a lot of dependencies, which you would not have in a regular empty console application
Console out: some test frameworks makes it difficult to write out to the console, for example in xUnit you can use a special dependency: ITestOutputHelper
Memory profiling is more difficult too: capturing GC heaps for comparisons brings a lot of objects into the view, that are allocated by the test framework
Test might be run in Debug
CI/CD pipelines with multiple build agents might measure different results because of different load/underlying hardware
In conclusion, I would still suggest to use regular Release built C# console apps with a well-known benchmark framework for performance testing.
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?