Skip to content
This repository has been archived by the owner on Jan 23, 2023. It is now read-only.
/ corefx Public archive

Benchmarking .NET Core 2.0/2.1 applications with BenchmarkDotNet #25612

Merged
merged 5 commits into from
Nov 30, 2017

Conversation

ViktorHofer
Copy link
Member

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)

@ViktorHofer ViktorHofer added the documentation Documentation bug or enhancement, does not impact product or test code label Nov 30, 2017
@ViktorHofer ViktorHofer added this to the 2.1.0 milestone Nov 30, 2017
@ViktorHofer ViktorHofer self-assigned this Nov 30, 2017
@ViktorHofer
Copy link
Member Author

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.
Copy link
Member

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.
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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);
}
}
```
Copy link
Member

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.

Copy link
Member

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
```
Copy link
Member

@danmoseley danmoseley Nov 30, 2017

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.
Copy link
Member

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

@Anipik
Copy link

Anipik commented Nov 30, 2017

Suggestion:- We can add this link http://benchmarkdotnet.org/ . It is useful for geting an overview and add custom features.

@stephentoub
Copy link
Member

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.

@ViktorHofer
Copy link
Member Author

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.

@ViktorHofer ViktorHofer merged commit 5aa98c1 into master Nov 30, 2017
@ViktorHofer ViktorHofer deleted the ViktorHofer-benchmark branch November 30, 2017 21:50
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
…net/corefx#25612)

* Benchmarking .NET Core 2.0/2.1 applications with BenchmarkDotNet


Commit migrated from dotnet/corefx@5aa98c1
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
documentation Documentation bug or enhancement, does not impact product or test code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants