-
Notifications
You must be signed in to change notification settings - Fork 4.9k
Benchmarking .NET Core 2.0/2.1 applications with BenchmarkDotNet #25612
Conversation
cc @Anipik |
@@ -0,0 +1,102 @@ | |||
# Benchmarking .NET Core 2.0 / 2.1 applications | |||
|
|||
In this example we are using **BenchmarkDotNet** (https://github.com/dotnet/BenchmarkDotNet) for our testing. Make sure to use the latest version which allows to specify a custom SKD path. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sdk
# Benchmarking .NET Core 2.1 applications | ||
Make sure to download the .NET Core 2.1 SDK zip archive (https://github.com/dotnet/core-setup#daily-builds) and extract it somewhere locally, e.g.: `C:\Program Files\dotnet-nightly\`. | ||
|
||
In this tutorial we won't modify the `PATH` variable and instead always explicitely call the `dotnet.exe` from the downloaded SDK folder. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
explicitly
|
||
|
||
|
||
### Using your self-compiled shared framework |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternative 2 ...
## Shared framework | ||
You can either decide to use your local self-compiled shared framework package or use the one from the .NET Core 2.1 SDK. | ||
|
||
### Using the shared framework from the .NET Core 2.1 SDK |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternative 1...
### Using the shared framework from the .NET Core 2.1 SDK | ||
Follow the instructions described here https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md#advanced-scenario---using-a-nightly-build-of-microsoftnetcoreapp and skip the last part which calls the `dotnet.exe`. | ||
|
||
Now we are going to create a BenchmarkDotNet configuration file to set the path to the .NET Core 2.1 SDK |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Save this as a .cs file and add it to your project.
Add(MemoryDiagnoser.Default); | ||
} | ||
} | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Defining your benchmark
See Benchmark.NET documentation -- minimally you need to adorn a public method with the [Benchmark]
attribute but there are many other ways to customize what is done such as using parameter sets or setup/cleanup methods.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Of course, you'll want to bracket just the relevant code in your benchmark, ensure there are sufficient iterations that you minimise noise, as well as leaving the machine otherwise idle while you measure.
> "C:\Program Files\dotnet-nightly\dotnet.exe" restore | ||
> "C:\Program Files\dotnet-nightly\dotnet.exe" build -c Release | ||
> "C:\Program Files\dotnet-nightly\dotnet.exe" run -c Release | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reporting results
Often in a PR or issue you will want to share performance results to justify a change. Benchmark.NET will have created a ???.md file in XXX folder which you can paste in, along with the code you benchmarked.
@@ -0,0 +1,102 @@ | |||
# Benchmarking .NET Core 2.0 / 2.1 applications | |||
|
|||
In this example we are using **BenchmarkDotNet** (https://github.com/dotnet/BenchmarkDotNet) for our testing. Make sure to use the latest version which allows to specify a custom SKD path. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We recommend using Benchmark.NET ... etc
Suggestion:- We can add this link http://benchmarkdotnet.org/ . It is useful for geting an overview and add custom features. |
FWIW, I've taken a different approach. Since I do a lot of my local testing in a flat directory containing bits I build locally for coreclr and corefx, I just have the BenchmarkDotNet.dll and BenchmarkDotNet.Core.dll assemblies in that same folder, and I build benchmarks against them by /r: 'ing them with csc.exe. Then I just annotate my benchmark with [InProcess]. It's not perfect, but it avoids a lot of the ceremony. |
Thanks Stephen! That's a handy detail for my other documentation which I need to finish (Demystifying .NET Core bits --> csc,... #24168) . I agree that as a DEV who is involved with constant testing, your way is easier. I will mention it there and will put a reference to this doc. |
…net/corefx#25612) * Benchmarking .NET Core 2.0/2.1 applications with BenchmarkDotNet Commit migrated from dotnet/corefx@5aa98c1
Instructions for using BenchmarkDotNet with .NET Core 2.0/2.1 (shared framework from either the nightly SDK or from your local built corefx package)