You've already forked linux-packaging-mono
Imported Upstream version 5.16.0.100
Former-commit-id: 38faa55fb9669e35e7d8448b15c25dc447f25767
This commit is contained in:
Xamarin Public Jenkins (auto-signing)
parent
0a9828183b
commit
7d7f676260
@@ -56,6 +56,10 @@ Ubuntu 16.10 and Ubuntu 17.04 will require libicu57.
|
||||
|
||||
`sudo apt-get install libunwind8 libicu55 curl`
|
||||
|
||||
Ubuntu 18 will also need compatibility OpenSSL 1.0.x
|
||||
|
||||
`sudo apt-get install libunwind8 libicu60 libssl1.0-dev curl`
|
||||
|
||||
In addition to the above packages, the runtime versions of the packages listed
|
||||
in the native section should also be installed (this happens automatically on
|
||||
most systems when you install the development packages).
|
||||
@@ -102,6 +106,25 @@ ln -s /usr/local/opt/openssl/lib/pkgconfig/libssl.pc /usr/local/lib/pkgconfig/
|
||||
ln -s /usr/local/opt/openssl/lib/pkgconfig/openssl.pc /usr/local/lib/pkgconfig/
|
||||
```
|
||||
|
||||
Alternatively, to avoid modifying /usr/local/ you can invoke cmake with the `OPENSSL_ROOT_DIR` env var set. The value to be passed in the directory where openssl is installed. Use `brew info openssl` to determine it. For example:
|
||||
|
||||
```
|
||||
$brew info openssl
|
||||
openssl: stable 1.0.2l (bottled) [keg-only]
|
||||
SSL/TLS cryptography library
|
||||
https://openssl.org/
|
||||
/usr/local/Cellar/openssl/1.0.1f (1,229 files, 10.8MB)
|
||||
Poured from bottle on 2014-01-20 at 19:25:30
|
||||
/usr/local/Cellar/openssl/1.0.1g (1,229 files, 10.6MB)
|
||||
Poured from bottle on 2014-04-07 at 11:26:41
|
||||
```
|
||||
|
||||
With the above example, we'd pick the latest version `1.0.1g` and invoke cmake like the following:
|
||||
|
||||
```
|
||||
OPENSSL_ROOT_DIR="/usr/local/Cellar/openssl/1.0.1g cmake
|
||||
```
|
||||
|
||||
### Known Issues
|
||||
If you see errors along the lines of `SendFailure (Error writing headers)` you may need to import trusted root certificates:
|
||||
|
||||
|
||||
@@ -137,4 +137,4 @@ where you removed types in order to maintain back-compat.
|
||||
- Remove old build configurations - The older build configurations will automatically be harvested from
|
||||
the last stable packages and thus can be removed.
|
||||
- Remove import statements - If not referencing any pre-netstandard stable packages the [imports of dotnet5.x](https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.Process/src/project.json#L28) are no longer needed and can be removed. We should also remove any dead target frameworks sections.
|
||||
- Remove all non-conditionsed `<AssemblyVersion>` properties from csproj's as it should be defined in library\dir.props.
|
||||
- Remove all non-conditioned `<AssemblyVersion>` properties from csproj's as it should be defined in library\dir.props.
|
||||
|
||||
@@ -49,11 +49,12 @@ Breaking Change Rules
|
||||
> For example, `CultureInfo.GetCultureInfo(String)` used to throw `ArgumentException` in .NET Framework 3.5. In .NET Framework 4.0, this was changed to throw `CultureNotFoundException` which derives from `ArgumentException`, and therefore is an acceptable change.
|
||||
|
||||
* Throwing a more specific exception than `NotSupportedException`, `NotImplementedException`, `NullReferenceException` or an exception that is considered unrecoverable
|
||||
> Unrecoverable exceptions should not be getting caught and will be dealt with on a broad level by a high-level catch-all handler. Therefore, users are not expected to have code that catches these explicit exceptions. The list of unrecoverable exceptions are:
|
||||
* `StackOverflowException`
|
||||
* `SEHException`
|
||||
* `ExecutionEngineException`
|
||||
* `AccessViolationException`
|
||||
> Unrecoverable exceptions should not be getting caught and will be dealt with on a broad level by a high-level catch-all handler. Therefore, users are not expected to have code that catches these explicit exceptions. The unrecoverable exceptions are:
|
||||
>
|
||||
> * `StackOverflowException`
|
||||
> * `SEHException`
|
||||
> * `ExecutionEngineException`
|
||||
> * `AccessViolationException`
|
||||
|
||||
* Throwing a new exception that only applies to a code-path which can only be observed with new parameter values, or state (that couldn't hit by existing code targeting the previous version)
|
||||
|
||||
@@ -131,6 +132,8 @@ Breaking Change Rules
|
||||
* Moving a type from one assembly into another assembly
|
||||
> The old assembly must be marked with `TypeForwardedToAttribute` pointing to the new location
|
||||
|
||||
* Changing a `struct` type to a `readonly struct` type
|
||||
|
||||
✗ **Disallowed**
|
||||
* Adding the `sealed` or `abstract` keyword to a type when there _are accessible_ (public or protected) constructors
|
||||
|
||||
@@ -143,6 +146,10 @@ Breaking Change Rules
|
||||
|
||||
* Changing the namespace or name of a type
|
||||
|
||||
* Changing a `readonly struct` type to a `struct` type
|
||||
|
||||
* Changing a `struct` type to a `ref struct` type and vice versa
|
||||
|
||||
### Members
|
||||
✓ **Allowed**
|
||||
* Adding an abstract member to a public type when there are _no accessible_ (`public` or `protected`) constructors, or the type is `sealed`
|
||||
@@ -158,6 +165,8 @@ Breaking Change Rules
|
||||
* Introducing or removing an override
|
||||
> Make note, that introducing an override might cause previous consumers to skip over the override when calling `base`.
|
||||
|
||||
* Change from `ref readonly` return to `ref` return (except for virtual methods or interfaces)
|
||||
|
||||
✗ **Disallowed**
|
||||
* Adding an member to an interface
|
||||
|
||||
@@ -180,6 +189,10 @@ successfully bind to that overload, if simply passing an `int` value. However, i
|
||||
* Adding `virtual` to a member
|
||||
> While this change would often work without breaking too many scenarios because C# compiler tends to emit `callvirt` IL instructions to call non-virtual methods (`callvirt` performs a null check, while a normal `call` won't), we can't rely on it. C# is not the only language we target and the C# compiler increasingly tries to optimize `callvirt` to a normal `call` whenever the target method is non-virtual and the `this` is provably not null (such as a method accessed through the `?.` null propagation operator). Making a method virtual would mean that consumer code would often end up calling it non-virtually.
|
||||
|
||||
* Change from `ref` return to `ref readonly` return
|
||||
|
||||
* Change from `ref readonly` return to `ref` return on a virtual method or interface
|
||||
|
||||
* Adding or removing `static` keyword from a member
|
||||
|
||||
### Signatures
|
||||
@@ -199,7 +212,7 @@ successfully bind to that overload, if simply passing an `int` value. However, i
|
||||
|
||||
* Removing `params` from a parameter
|
||||
|
||||
* Adding or removing `out` or `ref` keywords from a parameter
|
||||
* Adding or removing `in`, `out`, or `ref` keywords from a parameter
|
||||
|
||||
* Renaming a parameter (including case)
|
||||
> This is considered breaking for two reasons:
|
||||
|
||||
@@ -9,10 +9,10 @@ The general rule we follow is "use Visual Studio defaults".
|
||||
|
||||
1. We use [Allman style](http://en.wikipedia.org/wiki/Indent_style#Allman_style) braces, where each brace begins on a new line. A single line statement block can go without braces but the block must be properly indented on its own line and it must not be nested in other statement blocks that use braces (See issue [381](https://github.com/dotnet/corefx/issues/381) for examples).
|
||||
2. We use four spaces of indentation (no tabs).
|
||||
3. We use `_camelCase` for internal and private fields and use `readonly` where possible. Prefix instance fields with `_`, static fields with `s_` and thread static fields with `t_`. When used on static fields, `readonly` should come after `static` (i.e. `static readonly` not `readonly static`).
|
||||
3. We use `_camelCase` for internal and private fields and use `readonly` where possible. Prefix instance fields with `_`, static fields with `s_` and thread static fields with `t_`. When used on static fields, `readonly` should come after `static` (e.g. `static readonly` not `readonly static`).
|
||||
4. We avoid `this.` unless absolutely necessary.
|
||||
5. We always specify the visibility, even if it's the default (i.e.
|
||||
`private string _foo` not `string _foo`). Visibility should be the first modifier (i.e.
|
||||
5. We always specify the visibility, even if it's the default (e.g.
|
||||
`private string _foo` not `string _foo`). Visibility should be the first modifier (e.g.
|
||||
`public abstract` not `abstract public`).
|
||||
6. Namespace imports should be specified at the top of the file, *outside* of
|
||||
`namespace` declarations and should be sorted alphabetically.
|
||||
@@ -23,12 +23,13 @@ The general rule we follow is "use Visual Studio defaults".
|
||||
Consider enabling "View White Space (Ctrl+E, S)" if using Visual Studio, to aid detection.
|
||||
9. If a file happens to differ in style from these guidelines (e.g. private members are named `m_member`
|
||||
rather than `_member`), the existing style in that file takes precedence.
|
||||
10. We only use `var` when it's obvious what the variable type is (i.e. `var stream = new FileStream(...)` not `var stream = OpenStandardInput()`).
|
||||
11. We use language keywords instead of BCL types (i.e. `int, string, float` instead of `Int32, String, Single`, etc) for both type references as well as method calls (i.e. `int.Parse` instead of `Int32.Parse`). See issue [391](https://github.com/dotnet/corefx/issues/391) for examples.
|
||||
10. We only use `var` when it's obvious what the variable type is (e.g. `var stream = new FileStream(...)` not `var stream = OpenStandardInput()`).
|
||||
11. We use language keywords instead of BCL types (e.g. `int, string, float` instead of `Int32, String, Single`, etc) for both type references as well as method calls (e.g. `int.Parse` instead of `Int32.Parse`). See issue [391](https://github.com/dotnet/corefx/issues/391) for examples.
|
||||
12. We use PascalCasing to name all our constant local variables and fields. The only exception is for interop code where the constant value should exactly match the name and value of the code you are calling via interop.
|
||||
13. We use ```nameof(...)``` instead of ```"..."``` whenever possible and relevant.
|
||||
14. Fields should be specified at the top within type declarations.
|
||||
15. When including non-ASCII characters in the source code use Unicode escape sequences (\uXXXX) instead of literal characters. Literal non-ASCII characters occasionally get garbled by a tool or editor.
|
||||
16. When using labels (for goto), indent the label one less than the current indentation.
|
||||
|
||||
We have provided a Visual Studio 2013 vssettings file (`corefx.vssettings`) at the root of the corefx repository, enabling C# auto-formatting conforming to the above guidelines. Note that rules 7 and 8 are not covered by the vssettings, since these are not rules currently supported by VS formatting.
|
||||
|
||||
|
||||
@@ -65,13 +65,16 @@ lldb-3.9 -O "settings set target.exec-search-paths /home/parallels/Downloads/Sys
|
||||
|
||||
- Install [Visual Studio Code](https://code.visualstudio.com/)
|
||||
- Install the [C# Extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode.csharp)
|
||||
- Open the folder containing the source you want to debug in VS Code
|
||||
- Open the folder containing the source you want to debug in VS Code - i.e., if you are debugging a test failure in System.Net.Sockets, open `corefx/src/System.Net.Sockets`
|
||||
- Open the debug window: `ctrl-shift-D` or click on the button on the left
|
||||
- Click the gear button at the top to create a launch configuration, select `.NET Core` from the selection dropdown
|
||||
- In the `.NET Core Launch (console)` configuration do the following
|
||||
- delete the `preLaunchTask` property
|
||||
- set `program` to the full path to corerun in the test directory
|
||||
- set `cwd` to the test directory
|
||||
- set `program` to the full path to `dotnet` in the bin directory.
|
||||
- something like `corefx/bin/testhost/netcoreapp-Linux-{Configuration}-{Architecture}`, plus the full path to your corefx directory.
|
||||
- set `cwd` to the test bin directory.
|
||||
- using the System.Net.Sockets example, it should be something like `corefx/bin/tests/System.Net.Sockets.Tests/netcoreapp-Linux-{Configuration}-{Architecture}`, plus the full path to your corefx directory.
|
||||
- set `args` to the command line arguments to pass to the test
|
||||
- something like: `[ "xunit.console.netcore.exe", "<test>.dll", "-notrait", .... ]`
|
||||
- to run a specific test, you can append something like: `[ "method", "System.Net.Sockets.Tests.{ClassName}.{TestMethodName}", ...]`
|
||||
- Set a breakpoint and launch the debugger, inspecting variables and call stacks will now work
|
||||
|
||||
@@ -127,7 +127,7 @@ Logs are going to be placed in %SYSTEMDRIVE%\sockets.etl.
|
||||
|
||||
### Using PerfView
|
||||
|
||||
1. Install [PerfView](http://www.microsoft.com/en-us/download/details.aspx?id=28567)
|
||||
1. Install [PerfView](https://github.com/Microsoft/perfview/blob/master/documentation/Downloading.md)
|
||||
2. Run PerfView as Administrator
|
||||
3. Press Alt+C to collect events
|
||||
4. Disable all other collection parameters
|
||||
|
||||
@@ -4,7 +4,7 @@ We recommend using [BenchmarkDotNet](https://github.com/dotnet/BenchmarkDotNet)
|
||||
|
||||
```
|
||||
<ItemGroup>
|
||||
<PackageReference Include="BenchmarkDotNet" Version="0.10.11" />
|
||||
<PackageReference Include="BenchmarkDotNet" Version="0.10.13" />
|
||||
</ItemGroup>
|
||||
```
|
||||
|
||||
@@ -22,52 +22,151 @@ For the sake of this tutorial we won't modify the `PATH` variable and instead al
|
||||
|
||||
The shared framework is a set of assemblies that are packed into a `netcoreapp` Nuget package which is used when you set your `TargetFramework` to `netcoreappX.X`. You can either decide to use your local self-compiled shared framework package or use the one which is bundled with the .NET Core 2.1 SDK.
|
||||
|
||||
## 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` to run the application.
|
||||
# Benchmarking local CoreFX builds
|
||||
|
||||
Add a benchmark class, configure it either with a manual configuration or by attributing it and pass the class type to the BenchmarkRunner:
|
||||
Since `0.10.13` BenchmarkDotNet knows [how to](./dogfooding.md#more-advanced-scenario---using-your-local-corefx-build) build a self-contained app against local CoreFX build. You just need to provide it the version you would like to benchmark and path to the folder with NuGet packages.
|
||||
|
||||
```csharp
|
||||
[MemoryDiagnoser]
|
||||
// ...
|
||||
public class Benchmark
|
||||
**Important:** BenchmarkDotNet will generate the right `.csproj` file for the self-contained app. It's going to reference the `.csproj` file of the project which defines benchmarks. It's going to work even if your project is not self-contained app targeting local CoreFX build. So you can just create a new solution with console app in Visual Studio, install BenchmarkDotNet and it's going to do the right thing for you.
|
||||
|
||||
**Hint:** If you are curious to know what BDN does internally you just need to apply `[KeepBenchmarkFiles]` attribute to your class or set `KeepBenchmarkFiles = true` in your config file. After runing the benchmarks you can find the auto-generated files in `%pathToBenchmarkApp\bin\Release\$TFM\` folder.
|
||||
|
||||
```cs
|
||||
class Program
|
||||
{
|
||||
// Benchmark code ...
|
||||
}
|
||||
|
||||
public class Program
|
||||
{
|
||||
public static void Main()
|
||||
{
|
||||
BenchmarkRunner.Run<Benchmark>();
|
||||
}
|
||||
static void Main(string[] args)
|
||||
=> BenchmarkSwitcher.FromAssembly(typeof(Program).Assembly)
|
||||
.Run(args, DefaultConfig.Instance.With(
|
||||
Job.ShortRun.With(
|
||||
CustomCoreClrToolchain.CreateForLocalCoreFxBuild(
|
||||
@"C:\Projects\forks\corefx\bin\packages\Release",
|
||||
"4.5.0-preview2-26313-0"))));
|
||||
}
|
||||
```
|
||||
|
||||
## Alternative 2 - Using your self-compiled shared framework
|
||||
Follow the instructions described here https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md#more-advanced-scenario---using-your-local-corefx-build and skip the last part which calls the `dotnet.exe` to run the application.
|
||||
Make sure to build your local corefx repository in RELEASE mode `.\build -release`! You currently need to have a self-contained application to inject your local shared framework package.
|
||||
**Warning:** BDN is going to restore the NuGet packages and install them in your `.nuget` folder. Please keep in mind that [you either have to remove them](./dogfooding.md#3---consuming-subsequent-code-changes-by-overwriting-the-binary-alternative-1) or [increase the version number](./dogfooding.md#3---consuming-subsequent-code-changes-by-overwriting-the-binary-alternative-2) after making some code changes and rebuilding the repo. **Otherwise, you are going to benchmark the same code over and over again**.
|
||||
|
||||
Currently there is no straightforward way to run your BenchmarkDotNet application in a dedicated process, therefore we are using the InProcess switch `[InProcess]`:
|
||||
As an alternative to rebuilding entire CoreFX to regenerate the NuGet packages, you can provide the list of files that need to be copied to the published self-contained app. The files should be the dlls which you are trying to optimize. You can even define two jobs, one for the state before your local changes and one with the changes:
|
||||
|
||||
```csharp
|
||||
[InProcess]
|
||||
public class Benchmark
|
||||
```cs
|
||||
static void Main(string[] args)
|
||||
=> BenchmarkSwitcher.FromAssembly(typeof(Program).Assembly)
|
||||
.Run(args, DefaultConfig.Instance
|
||||
.With(Job.ShortRun
|
||||
.With(CustomCoreClrToolchain.CreateForLocalCoreFxBuild(
|
||||
pathToNuGetFolder: @"C:\Projects\forks\corefx\bin\packages\Release",
|
||||
privateCoreFxNetCoreAppVersion: "4.5.0-preview2-26313-0",
|
||||
displayName: "before"))
|
||||
.AsBaseline()
|
||||
.WithId("before"))
|
||||
.With(Job.ShortRun
|
||||
.With(CustomCoreClrToolchain.CreateForLocalCoreFxBuild(
|
||||
pathToNuGetFolder: @"C:\Projects\forks\corefx\bin\packages\Release",
|
||||
privateCoreFxNetCoreAppVersion: "4.5.0-preview2-26313-0",
|
||||
displayName: "after",
|
||||
filesToCopy: new [] {
|
||||
@"c:\Projects\forks\corefx\bin\AnyOS.AnyCPU.Release\System.Text.RegularExpressions\netcoreapp\System.Text.RegularExpressions.dll"
|
||||
}))
|
||||
.WithId("after"))
|
||||
.KeepBenchmarkFiles());
|
||||
```
|
||||
|
||||
Once you run the benchmarks with such a config it should be clear if you have improved the performance or not (like in the example below):
|
||||
|
||||
| Method | Job | Toolchain | IsBaseline | Mean | Error | StdDev | Scaled | ScaledSD |
|
||||
|------- |------- |---------- |----------- |----------:|---------:|----------:|-------:|---------:|
|
||||
| Sample | after | after | Default | 35.077 us | 3.363 us | 0.1900 us | 8.64 | 0.15 |
|
||||
| Sample | before | before | True | 4.060 us | 1.465 us | 0.0828 us | 1.00 | 0.00 |
|
||||
|
||||
# Benchmarking nightly CoreFX builds
|
||||
|
||||
Since `0.10.13` BenchmarkDotNet knows [how to](./dogfooding.md#advanced-scenario---using-a-nightly-build-of-microsoftnetcoreap) build a self-contained app against nightly CoreFX build. You just need to provide it the version you would like to benchmark. You don't need to provide url to MyGet feed, the default value is "https://dotnet.myget.org/F/dotnet-core/api/v3/index.json".
|
||||
|
||||
```cs
|
||||
static void Main(string[] args)
|
||||
=> BenchmarkSwitcher.FromAssembly(typeof(Program).Assembly)
|
||||
.Run(args, DefaultConfig.Instance
|
||||
.With(Job.ShortRun
|
||||
.With(CustomCoreClrToolchain.CreateForNightlyCoreFxBuild("4.5.0-preview2-26215-01"))));
|
||||
```
|
||||
|
||||
**Hint:** If you would like to compare the performance of different CoreFX versions, you just need to define multiple jobs, each using it's own toolchain.
|
||||
|
||||
```cs
|
||||
DefaultConfig.Instance
|
||||
.With(Job.Default.With(CustomCoreClrToolchain.CreateForNightlyCoreFxBuild("4.5.0-preview2-26214-01", displayName: "before my change")));
|
||||
.With(Job.Default.With(CustomCoreClrToolchain.CreateForNightlyCoreFxBuild("4.5.0-preview2-26215-01", displayName: "after my change")));
|
||||
```
|
||||
|
||||
# Benchmarking ANY CoreCLR and CoreFX builds
|
||||
|
||||
BenchmarkDotNet allows you to benchmark **ANY** CoreCLR and CoreFX builds. It just generates the right `.csproj` file with appropriate dependencies and `NuGet.config` file with the right feeds.
|
||||
|
||||
Example:
|
||||
|
||||
```
|
||||
public class LocalCoreClrConfig : ManualConfig
|
||||
{
|
||||
// Benchmark code ...
|
||||
}
|
||||
public LocalCoreClrConfig()
|
||||
{
|
||||
Add(Job.ShortRun.With(
|
||||
new CustomCoreClrToolchain(
|
||||
"local builds",
|
||||
coreClrNuGetFeed: @"C:\Projects\forks\coreclr\bin\Product\Windows_NT.x64.Release\.nuget\pkg",
|
||||
coreClrVersion: "2.1.0-preview2-26313-0",
|
||||
coreFxNuGetFeed: @"C:\Projects\forks\corefx\bin\packages\Release",
|
||||
coreFxVersion: "4.5.0-preview2-26313-0")
|
||||
));
|
||||
|
||||
public class Program
|
||||
{
|
||||
public static void Main()
|
||||
{
|
||||
BenchmarkRunner.Run<Benchmark>();
|
||||
}
|
||||
Add(Job.ShortRun.With(
|
||||
new CustomCoreClrToolchain(
|
||||
"local coreclr myget corefx",
|
||||
coreClrNuGetFeed: @"C:\Projects\forks\coreclr\bin\Product\Windows_NT.x64.Release\.nuget\pkg",
|
||||
coreClrVersion: "2.1.0-preview2-26313-0",
|
||||
coreFxNuGetFeed: "https://dotnet.myget.org/F/dotnet-core/api/v3/index.json",
|
||||
coreFxVersion: "4.5.0-preview2-26215-01")
|
||||
));
|
||||
|
||||
Add(Job.ShortRun.With(
|
||||
new CustomCoreClrToolchain(
|
||||
"myget coreclr local corefx",
|
||||
coreClrNuGetFeed: "https://dotnet.myget.org/F/dotnet-core/api/v3/index.json",
|
||||
coreClrVersion: "2.1.0-preview2-26214-07",
|
||||
coreFxNuGetFeed: @"C:\Projects\forks\corefx\bin\packages\Release",
|
||||
coreFxVersion: "4.5.0-preview2-26313-0")
|
||||
));
|
||||
|
||||
Add(Job.ShortRun.With(
|
||||
new CustomCoreClrToolchain(
|
||||
"myget builds",
|
||||
coreClrNuGetFeed: "https://dotnet.myget.org/F/dotnet-core/api/v3/index.json",
|
||||
coreClrVersion: "2.1.0-preview2-26214-07",
|
||||
coreFxNuGetFeed: "https://dotnet.myget.org/F/dotnet-core/api/v3/index.json",
|
||||
coreFxVersion: "4.5.0-preview2-26215-01")
|
||||
));
|
||||
|
||||
// the rest of the config..
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The output is going to contain exact CoreCLR and CoreFX versions used:
|
||||
|
||||
```
|
||||
BenchmarkDotNet=v0.10.12.20180215-develop, OS=Windows 10 Redstone 3 [1709, Fall Creators Update] (10.0.16299.192)
|
||||
Intel Core i7-3687U CPU 2.10GHz (Ivy Bridge), 1 CPU, 4 logical cores and 2 physical cores
|
||||
Frequency=2533308 Hz, Resolution=394.7408 ns, Timer=TSC
|
||||
.NET Core SDK=2.1.300-preview2-008162
|
||||
[Host] : .NET Core 2.0.5 (CoreCLR 4.6.26020.03, CoreFX 4.6.26018.01), 64bit RyuJIT
|
||||
Job-DHYYZE : .NET Core ? (CoreCLR 4.6.26313.0, CoreFX 4.6.26313.0), 64bit RyuJIT
|
||||
Job-VGTPFY : .NET Core ? (CoreCLR 4.6.26313.0, CoreFX 4.6.26215.01), 64bit RyuJIT
|
||||
Job-IYZFNW : .NET Core ? (CoreCLR 4.6.26214.07, CoreFX 4.6.26215.01), 64bit RyuJIT
|
||||
Job-CTQFFQ : .NET Core ? (CoreCLR 4.6.26214.07, CoreFX 4.6.26313.0), 64bit RyuJIT
|
||||
```
|
||||
|
||||
**Warning:** To fully understand the results you need to know what optimizations (PGO, CrossGen) were applied to given build. Usually, CoreCLR installed with the .NET Core SDK will be fully optimized and the fastest. On Windows, you can use the [disassembly diagnoser](http://adamsitnik.com/Disassembly-Diagnoser/) to check the produced assembly code.
|
||||
|
||||
# Benchmark multiple or custom .NET Core 2.x SDKs
|
||||
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` to run the application.
|
||||
Follow the instructions described [here](./dogfooding.md#advanced-scenario---using-a-nightly-build-of-microsoftnetcoreapp) and skip the last part which calls the `dotnet.exe` to run the application.
|
||||
|
||||
Whenever you want to benchmark an application simultaneously with one or multiple different .NET Core run time framework versions, you want to create a manual BenchmarkDotNet configuration file. Add the desired amount of Jobs and `NetCoreAppSettings` to specify the `targetFrameworkMoniker`, `runtimeFrameworkVersion` and `customDotNetCliPath`:
|
||||
|
||||
|
||||
@@ -252,6 +252,13 @@ There may be multiple projects in some directories so you may need to specify th
|
||||
|
||||
Tests participate in the incremental build. This means that if tests have already been run, and inputs to the incremental build have not changed, rerunning the tests target will not execute the test runner again. To force re-executing tests in this situation, use `/p:ForceRunTests=true`.
|
||||
|
||||
#### Running a single test on the command line
|
||||
|
||||
To quickly run or debug a single test from the command line, set the XunitMethodName property (found in Tools\tests.targets) to the full method name (including namespace), e.g.:
|
||||
```cmd
|
||||
msbuild /t:RebuildAndTest /p:XunitMethodName={FullyQualifiedNamespace}.{ClassName}.{MethodName}
|
||||
```
|
||||
|
||||
#### Running tests in a different target framework
|
||||
|
||||
Each test project can potentially have multiple build configurations. There are some tests that might be OS-specific, or might be testing an API that is available only on some target frameworks, so the `BuildConfigurations` property specifies the valid configurations. By default we will build and run only the default build configuration which is `netcoreapp`. The rest of the configurations will need to be built and ran by specifying the configuration options.
|
||||
|
||||
@@ -14,26 +14,26 @@ this experience. Make sure to consult this document often.
|
||||
|
||||
3. Reminder: if you are using a local copy of the dotnet CLI, take care that when you type `dotnet` you do not inadvertently pick up a different copy that you may have in your path. On Windows, for example, if you use a Developer Command Prompt, a global copy may be in the path, so use the fully qualified path to your local `dotnet`. If you receive an error "The current .NET SDK does not support targeting .NET Core 2.1." then you may be executing an older `dotnet`.
|
||||
|
||||
After setting up dotnet you can verify you are using the newer version by executing `dotnet --info` -- the version should be greater than 2.2.0-* (dotnet CLI is currently numbered 2.2.0-* not 2.1.0-* ). Here is an example output at the time of writing:
|
||||
After setting up dotnet you can verify you are using the newer version by executing `dotnet --info` -- the version should be greater than `2.1.300-*` (dotnet CLI for .NET Core 2.1 is currently numbered `2.1.300-*`). Here is an example output at the time of writing:
|
||||
```
|
||||
>dotnet.exe --info
|
||||
.NET Command Line Tools (2.2.0-preview1-007460)
|
||||
.NET Command Line Tools (2.1.300-preview2-008171)
|
||||
|
||||
Product Information:
|
||||
Version: 2.2.0-preview1-007460
|
||||
Commit SHA-1 hash: 173cc035e4
|
||||
Version: 2.1.300-preview2-008171
|
||||
Commit SHA-1 hash: fbc76ea5f6
|
||||
|
||||
Runtime Environment:
|
||||
OS Name: Windows
|
||||
OS Version: 10.0.16299
|
||||
OS Platform: Windows
|
||||
RID: win10-x64
|
||||
Base Path: F:\dotnet\sdk\2.2.0-preview1-007460\
|
||||
Base Path: F:\dotnet\sdk\2.1.300-preview2-008171\
|
||||
|
||||
Microsoft .NET Core Shared Framework Host
|
||||
|
||||
Version : 2.1.0-preview1-25825-07
|
||||
Build : 4c165c13bd390adf66f9af30a088d634d3f37a9d
|
||||
Version : 2.1.0-preview2-26209-04
|
||||
Build : 5df6e9b7ab674a461b2a7f01ac87fb6e0ca06666
|
||||
```
|
||||
|
||||
4. Our nightly builds are uploaded to MyGet, not NuGet - so ensure the .NET Core MyGet feed is in your nuget configuration in case you need other packages from .NET Core that aren't included in the download. For example, on Windows you could edit `%userprofile%\appdata\roaming\nuget\nuget.config` or on Linux edit `~/.nuget/NuGet/NuGet.Config` to add this line:
|
||||
|
||||
@@ -42,7 +42,7 @@ Areas are tracked by labels area-* (e.g. area-System.Collections). Each area
|
||||
|
||||
| Area | Owners / experts | Description |
|
||||
|-----------------------------------------------------------------------------------------------|------------------|-------------|
|
||||
| [area-Infrastructure](https://github.com/dotnet/corefx/labels/area-Infrastructure) | [@weshaggard](https://github.com/weshaggard), [@ericstj](https://github.com/ericstj) |Covers:<ul><li>Packaging</li><li>Build and test infra for CoreFX repo</li><li>VS integration</li></ul><br/> |
|
||||
| [area-Infrastructure](https://github.com/dotnet/corefx/labels/area-Infrastructure) | [@weshaggard](https://github.com/weshaggard), [@ericstj](https://github.com/ericstj) | Covers:<ul><li>Packaging</li><li>Build and test infra for CoreFX repo</li><li>VS integration</li></ul><br/> |
|
||||
| [area-Meta](https://github.com/dotnet/corefx/labels/area-Meta) | [@tarekgh](https://github.com/tarekgh) | Issues without clear association to any specific API/contract, e.g. <ul><li>new contract proposals</li><li>cross-cutting code/test pattern changes (e.g. FxCop failures)</li><li>project-wide docs</li></ul><br/> |
|
||||
| [area-Serialization](https://github.com/dotnet/corefx/labels/area-Serialization) | [@huanwu](https://github.com/huanwu), [@zhenlan](https://github.com/zhenlan) | Packages:<ul><li>System.Runtime.Serialization.Xml</li><li>System.Runtime.Serialization.Json</li><li>System.Private.DataContractSerialization</li><li>System.Xml.XmlSerializer</li></ul> Excluded:<ul><li>System.Runtime.Serialization.Formatters</li></ul> |
|
||||
| **System contract assemblies** | | |
|
||||
@@ -55,27 +55,28 @@ Areas are tracked by labels area-* (e.g. area-System.Collections). Each area
|
||||
| [System.Composition](https://github.com/dotnet/corefx/labels/area-System.Composition) | **[@maryamariyan](https://github.com/maryamariyan)**, [@ViktorHofer](https://github.com/ViktorHofer) | |
|
||||
| [System.Configuration](https://github.com/dotnet/corefx/labels/area-System.Configuration) | [@maryamariyan](https://github.com/maryamariyan) | |
|
||||
| [System.Console](https://github.com/dotnet/corefx/labels/area-System.Console) | **[@joperezr](https://github.com/joperezr)**, [@ianhays](https://github.com/ianhays) | |
|
||||
| [System.Data](https://github.com/dotnet/corefx/labels/area-System.Data) | [@saurabh500](https://github.com/saurabh500), [@corivera](https://github.com/corivera) | |
|
||||
| [System.Data.SqlClient](https://github.com/dotnet/corefx/labels/area-System.Data.SqlClient) | [@saurabh500](https://github.com/saurabh500), [@corivera](https://github.com/corivera) | |
|
||||
| [System.Data](https://github.com/dotnet/corefx/labels/area-System.Data) | **[@divega](https://github.com/divega)**, [@ajcvickers](https://github.com/ajcvickers), [@keeratsingh](https://github.com/keeratsingh), [@afsanehr](https://github.com/afsanehr), [@david-engel](https://github.com/david-engel) | |
|
||||
| [System.Data.SqlClient](https://github.com/dotnet/corefx/labels/area-System.Data.SqlClient) | **[@keeratsingh](https://github.com/keeratsingh)**, [@afsanehr](https://github.com/afsanehr), [@david-engel](https://github.com/david-engel) | |
|
||||
| [System.Diagnostics](https://github.com/dotnet/corefx/labels/area-System.Diagnostics) | **[@joperezr](https://github.com/joperezr)**, [@wtgodbe](https://github.com/wtgodbe) | <ul><li>System.Diagnostics.EventLog [@Anipik](https://github.com/Anipik)</li></ul> |
|
||||
| [System.Diagnostics.Process](https://github.com/dotnet/corefx/labels/area-System.Diagnostics.Process) | **[@joperezr](https://github.com/joperezr)**, [@wtgodbe](https://github.com/wtgodbe) | |
|
||||
| [System.Diagnostics.Tracing](https://github.com/dotnet/corefx/labels/area-System.Diagnostics.Tracing) | [@brianrob](https://github.com/brianrob), [@vancem](https://github.com/vancem), [@valenis](https://github.com/valenis)| Packages:<ul><li>System.Diagnostics.DiagnosticSource</li><li>System.Diagnostics.PerformanceCounter - [@adiaaida](https://github.com/adiaaida)</li><li>System.Diagnostics.Tracing</li><li>System.Diagnostics.TraceSource</li></ul><br/> |
|
||||
| [System.DirectoryServices](https://github.com/dotnet/corefx/labels/area-System.DirectoryServices) | [@tquerec](https://github.com/tquerec) | |
|
||||
| [System.Diagnostics.Tracing](https://github.com/dotnet/corefx/labels/area-System.Diagnostics.Tracing) | [@brianrob](https://github.com/brianrob), [@vancem](https://github.com/vancem), [@valenis](https://github.com/valenis) | Packages:<ul><li>System.Diagnostics.DiagnosticSource</li><li>System.Diagnostics.PerformanceCounter - [@adiaaida](https://github.com/adiaaida)</li><li>System.Diagnostics.Tracing</li><li>System.Diagnostics.TraceSource</li></ul><br/> |
|
||||
| [System.DirectoryServices](https://github.com/dotnet/corefx/labels/area-System.DirectoryServices) | [@tquerec](https://github.com/tquerec), [@josephisenhour](https://github.com/josephisenhour), [@bongiovimatthew-microsoft](https://github.com/bongiovimatthew-microsoft) | |
|
||||
| [System.Drawing](https://github.com/dotnet/corefx/labels/area-System.Drawing) | [@safern](https://github.com/safern) | |
|
||||
| [System.Dynamic.Runtime](https://github.com/dotnet/corefx/labels/area-System.Dynamic.Runtime) | [@VSadov](https://github.com/VSadov), [@OmarTawfik](https://github.com/OmarTawfik) | |
|
||||
| [System.Globalization](https://github.com/dotnet/corefx/labels/area-System.Globalization) | **[@krwq](https://github.com/krwq)**, [@tarekgh](https://github.com/tarekgh) | |
|
||||
| [System.IO](https://github.com/dotnet/corefx/labels/area-System.IO) | **[@JeremyKuhne](https://github.com/JeremyKuhne)**, [@pjanotti](https://github.com/pjanotti) | |
|
||||
| [System.IO.Compression](https://github.com/dotnet/corefx/labels/area-System.IO.Compression) | **[@ViktorHofer](https://github.com/ViktorHofer)**, [@ianhays](https://github.com/ianhays) | |
|
||||
| [System.IO.Pipelines](https://github.com/dotnet/corefx/labels/area-System.IO.Pipelines) | **[@pakrym](https://github.com/pakrym)**, [@davidfowl](https://github.com/davidfowl) | |
|
||||
| [System.Linq](https://github.com/dotnet/corefx/labels/area-System.Linq) | [@VSadov](https://github.com/VSadov), [@OmarTawfik](https://github.com/OmarTawfik) | |
|
||||
| [System.Linq.Expressions](https://github.com/dotnet/corefx/labels/area-System.Linq.Expressions) | [@VSadov](https://github.com/VSadov), [@OmarTawfik](https://github.com/OmarTawfik) | |
|
||||
| [System.Linq.Parallel](https://github.com/dotnet/corefx/labels/area-System.Linq.Parallel) | **[@tarekgh](https://github.com/tarekgh)**, [@kouvel](https://github.com/kouvel) | |
|
||||
| [System.Management](https://github.com/dotnet/corefx/labels/area-System.Management) | **[@Anipik](https://github.com/Anipik)**, [@pjanotti](https://github.com/pjanotti) | WMI |
|
||||
| [System.Memory](https://github.com/dotnet/corefx/labels/area-System.Memory) | [@KrzysztofCwalina](https://github.com/KrzysztofCwalina), [@ahsonkhan](https://github.com/ahsonkhan) | |
|
||||
| [System.Net](https://github.com/dotnet/corefx/labels/area-System.Net) | [@davidsh](https://github.com/davidsh), [@Priya91](https://github.com/Priya91), [@wfurt](https://github.com/wfurt) | Included:<ul><li>System.Uri</li></ul> |
|
||||
| [System.Net.Http](https://github.com/dotnet/corefx/labels/area-System.Net.Http) | [@davidsh](https://github.com/davidsh), [@Priya91](https://github.com/Priya91), [@wfurt](https://github.com/wfurt) | |
|
||||
| [System.Net.Http.ManagedHandler](https://github.com/dotnet/corefx/labels/area-System.Net.Http.ManagedHandler) | [@geoffkizer](https://github.com/geoffkizer), [@Priya91](https://github.com/Priya91), [@wfurt](https://github.com/wfurt), [@davidsh](https://github.com/davidsh) | |
|
||||
| [System.Net.Security](https://github.com/dotnet/corefx/labels/area-System.Net.Security) | [@davidsh](https://github.com/davidsh), [@Priya91](https://github.com/Priya91), [@wfurt](https://github.com/wfurt) | |
|
||||
| [System.Net.Sockets](https://github.com/dotnet/corefx/labels/area-System.Net.Sockets) | [@davidsh](https://github.com/davidsh), [@Priya91](https://github.com/Priya91), [@wfurt](https://github.com/wfurt) | |
|
||||
| [System.Memory](https://github.com/dotnet/corefx/labels/area-System.Memory) | **[@ahsonkhan](https://github.com/ahsonkhan)**, [@KrzysztofCwalina](https://github.com/KrzysztofCwalina) | |
|
||||
| [System.Net](https://github.com/dotnet/corefx/labels/area-System.Net) | [@davidsh](https://github.com/davidsh), [@wfurt](https://github.com/wfurt), [@caesar1995](https://github.com/caesar1995), [@rmkerr](https://github.com/rmkerr), [@karelz](https://github.com/karelz) | Included:<ul><li>System.Uri</li></ul> |
|
||||
| [System.Net.Http](https://github.com/dotnet/corefx/labels/area-System.Net.Http) | [@davidsh](https://github.com/davidsh), [@wfurt](https://github.com/wfurt), [@caesar1995](https://github.com/caesar1995), [@rmkerr](https://github.com/rmkerr), [@karelz](https://github.com/karelz) | |
|
||||
| [System.Net.Http.SocketsHttpHandler](https://github.com/dotnet/corefx/labels/area-System.Net.Http.SocketsHttpHandler) | [@geoffkizer](https://github.com/geoffkizer), [@wfurt](https://github.com/wfurt), [@davidsh](https://github.com/davidsh), [@karelz](https://github.com/karelz) | |
|
||||
| [System.Net.Security](https://github.com/dotnet/corefx/labels/area-System.Net.Security) | [@davidsh](https://github.com/davidsh), [@wfurt](https://github.com/wfurt), [@caesar1995](https://github.com/caesar1995), [@rmkerr](https://github.com/rmkerr), [@karelz](https://github.com/karelz) | |
|
||||
| [System.Net.Sockets](https://github.com/dotnet/corefx/labels/area-System.Net.Sockets) | [@davidsh](https://github.com/davidsh), [@wfurt](https://github.com/wfurt), [@caesar1995](https://github.com/caesar1995), [@rmkerr](https://github.com/rmkerr), [@karelz](https://github.com/karelz) | |
|
||||
| [System.Numerics](https://github.com/dotnet/corefx/labels/area-System.Numerics) | [@eerhardt](https://github.com/eerhardt), [@ViktorHofer](https://github.com/ViktorHofer) | |
|
||||
| [System.Reflection](https://github.com/dotnet/corefx/labels/area-System.Reflection) | [@AtsushiKan](https://github.com/AtsushiKan) | |
|
||||
| [System.Reflection.Emit](https://github.com/dotnet/corefx/labels/area-System.Reflection.Emit) | [@AtsushiKan](https://github.com/AtsushiKan) | |
|
||||
@@ -87,23 +88,32 @@ Areas are tracked by labels area-* (e.g. area-System.Collections). Each area
|
||||
| [System.Runtime.Extensions](https://github.com/dotnet/corefx/labels/area-System.Runtime.Extensions) | **[@joperezr](https://github.com/joperezr)**, [@AlexGhiondea](https://github.com/AlexGhiondea) | |
|
||||
| [System.Runtime.InteropServices](https://github.com/dotnet/corefx/labels/area-System.Runtime.InteropServices) | [@luqunl](https://github.com/luqunl), [@shrah](https://github.com/shrah) | Excluded:<ul><li>System.Runtime.InteropServices.RuntimeInfo</li></ul> |
|
||||
| [System.Runtime.Intrinsics](https://github.com/dotnet/corefx/labels/area-System.Runtime.Intrinsics) | [@eerhardt](https://github.com/eerhardt), [@CarolEidt](https://github.com/CarolEidt), [@RussKeldorph](https://github.com/RussKeldorph) | |
|
||||
| [System.Security](https://github.com/dotnet/corefx/labels/area-System.Security) | [@bartonjs](https://github.com/bartonjs), [@ianhays](https://github.com/ianhays) | |
|
||||
| [System.Security](https://github.com/dotnet/corefx/labels/area-System.Security) | **[@bartonjs](https://github.com/bartonjs)**, [@GrabYourPitchforks](https://github.com/GrabYourPitchforks) | |
|
||||
| System.ServiceModel | N/A | [dotnet/wcf](https://github.com/dotnet/wcf) (except System.ServiceModel.Syndication) |
|
||||
| [System.ServiceModel.Syndication](https://github.com/dotnet/corefx/labels/area-System.ServiceModel.Syndication) | [@huanwu](https://github.com/huanwu), [@zhenlan](https://github.com/zhenlan) | |
|
||||
| [System.ServiceProcess](https://github.com/dotnet/corefx/labels/area-System.ServiceProcess) | **[@maryamariyan](https://github.com/maryamariyan)**, [@Anipik](https://github.com/Anipik) | |
|
||||
| [System.Text.Encoding](https://github.com/dotnet/corefx/labels/area-System.Text.Encoding) | **[@krwq](https://github.com/krwq)**, [@tarekgh](https://github.com/tarekgh) | Included:<ul><li>System.Text.Encoding**s**.Web</li></ul> |
|
||||
| [System.Text.RegularExpressions](https://github.com/dotnet/corefx/labels/area-System.Text.RegularExpressions) | **[@ViktorHofer](https://github.com/ViktorHofer)**, [@Priya91](https://github.com/Priya91) | |
|
||||
| [System.Text.Encoding](https://github.com/dotnet/corefx/labels/area-System.Text.Encoding) | **[@krwq](https://github.com/krwq)**, [@tarekgh](https://github.com/tarekgh) | |
|
||||
| [System.Text.Encodings.Web](https://github.com/dotnet/corefx/labels/area-System.Text.Encodings.Web) | **[@GrabYourPitchforks](https://github.com/GrabYourPitchforks)**, [@krwq](https://github.com/krwq), [@tarekgh](https://github.com/tarekgh) | |
|
||||
| [System.Text.RegularExpressions](https://github.com/dotnet/corefx/labels/area-System.Text.RegularExpressions) | [@ViktorHofer](https://github.com/ViktorHofer) | |
|
||||
| [System.Threading](https://github.com/dotnet/corefx/labels/area-System.Threading) | **[@kouvel](https://github.com/kouvel)**| |
|
||||
| [System.Threading.Channels](https://github.com/dotnet/corefx/labels/area-System.Threading.Channels) | **[@tarekgh](https://github.com/tarekgh)**| |
|
||||
| [System.Threading.Tasks](https://github.com/dotnet/corefx/labels/area-System.Threading.Tasks) | **[@tarekgh](https://github.com/tarekgh)**| |
|
||||
| [System.Transactions](https://github.com/dotnet/corefx/labels/area-System.Transactions) | [@jimcarley](https://github.com/jimcarley), [@qizhanMS](https://github.com/qizhanMS), [@dmetzgar](https://github.com/dmetzgar) | |
|
||||
| [System.Xml](https://github.com/dotnet/corefx/labels/area-System.Xml) | **[@krwq](https://github.com/krwq)**, [@pjanotti](https://github.com/pjanotti) | |
|
||||
| **Microsoft contract assemblies** | | |
|
||||
| [Microsoft.CSharp](https://github.com/dotnet/corefx/labels/area-Microsoft.CSharp) | [@VSadov](https://github.com/VSadov), [@OmarTawfik](https://github.com/OmarTawfik) | |
|
||||
| [Microsoft.VisualBasic](https://github.com/dotnet/corefx/labels/area-Microsoft.VisualBasic) | [@VSadov](https://github.com/VSadov), [@OmarTawfik](https://github.com/OmarTawfik) | |
|
||||
| [Microsoft.Win32](https://github.com/dotnet/corefx/labels/area-Microsoft.Win32) | **[@maryamariyan](https://github.com/maryamariyan)**, , [@Anipik](https://github.com/Anipik) | |
|
||||
| [Microsoft.Win32](https://github.com/dotnet/corefx/labels/area-Microsoft.Win32) | **[@maryamariyan](https://github.com/maryamariyan)**, [@Anipik](https://github.com/Anipik) | |
|
||||
|
||||
|
||||
Note: Area triage will apply the new scheme (issue types and assignee) throughout 2016.
|
||||
|
||||
### Community Partner Experts
|
||||
|
||||
| Area | Owners / experts | Description |
|
||||
|-------------|------------------|-------------|
|
||||
| Tizen | [@alpencolt](https://github.com/alpencolt), [@gbalykov](https://github.com/gbalykov) | For issues around Tizen CI and build issues |
|
||||
|
||||
### Triage rules - simplified
|
||||
|
||||
1. Each issue has exactly one **area-*** label
|
||||
|
||||
@@ -1,49 +1,31 @@
|
||||
Performance Tests
|
||||
Performance Tests
|
||||
======================
|
||||
|
||||
This document contains instructions for building, running, and adding Performance tests.
|
||||
|
||||
Requirements
|
||||
--------------------
|
||||
### Windows
|
||||
To run performance tests on Windows, .NET portable v5.0 is required. This library is included in [the Visual Studio Community 2015 download](https://www.visualstudio.com/products/visual-studio-community-vs). To get the correct packages during installation, follow these steps after opening the installer:
|
||||
1. Select "Custom Installation" if no installation is present, or "Modify" otherwise
|
||||
2. Check the "Universal Windows App Development Tools" box under the "Windows and Web Development" menu
|
||||
3. Install
|
||||
### Linux
|
||||
Performance tests on Linux require all of the same steps as they do for regular xunit tests - see the linux instructions [here](https://github.com/dotnet/corefx/blob/master/Documentation/building/unix-instructions.md). Once you can have a directory on your Linux machine with a working corerun and xunit.console.netcore.exe (as well as the test dll containing your perf tests!), you only need to run the following command:
|
||||
|
||||
`dnu commands install Microsoft.DotNet.xunit.performance.runner.dnx 1.0.0-alpha-build0021 -f https://dotnet.myget.org/F/dotnet-buildtools/api/v3/index.json`
|
||||
|
||||
Be careful that your mscorlib, libcoreclr, and test dlls were compiled using the "/p:Configuration=Release" property. Otherwise you may get skewed results.
|
||||
|
||||
Running the tests
|
||||
Building and Running Tests
|
||||
-----------
|
||||
### Windows
|
||||
Performance test files (if present) are stored within a library's ```tests/Performance``` directory and contain test methods that are all marked with a perf-specific *Benchmark* attribute. The performance tests will only be run if the ```performance``` property is set to ```true```.
|
||||
Performance test files (if present) are stored within a library's ```tests/Performance``` directory and contain test methods that are all marked with a perf-specific *Benchmark* attribute.
|
||||
|
||||
Before running the performance tests you must run ```build -release``` from the root folder.
|
||||
**Step # 1:** Prior to running performance tests, a full build from the repo root must be completed: ```build -release```
|
||||
|
||||
To build and run the tests using msbuild for a project, run ```msbuild /t:BuildAndTest /p:Performance=true /p:ConfigurationGroup=Release /p:TargetOS=Windows_NT``` from the Performance directory with Admin privileges. If the v5.0 assemblies aren't installed on your system, an error will be raised and no tests will be run.
|
||||
**Step # 2:** Change directory to the performance tests directory: ```cd path/to/library/tests/Performance```
|
||||
|
||||
Note: Because build.cmd runs tests concurrently, it's not recommended that you execute the perf tests using it.
|
||||
**Step # 3:** Build and run the tests:
|
||||
- Windows (using admin command shell): ```msbuild /t:BuildAndTest /p:Performance=true /p:ConfigurationGroup=Release /p:TargetOS=Windows_NT```
|
||||
- Linux: ```<repo-root>/Tools/msbuild.sh /t:BuildAndTest /p:Performance=true /p:ConfigurationGroup=Release /p:TargetOS=Linux```
|
||||
|
||||
results will be in: corefx/bin/tests/Windows_NT.AnyCPU.Release/TESTNAME/netcoreapp1.0
|
||||
### Linux
|
||||
From your tests directory, run:
|
||||
```
|
||||
xunit.performance System.Collections.Tests.dll -trait Benchmark=true -verbose -runner ./xunit.console.netcore.exe -runnerhost ./corerun -runid System.Collections.Tests.dll-Linux -outdir results
|
||||
```
|
||||
**Note: Because build-tests.cmd/sh runs tests concurrently, do not use it for executing performance tests.**
|
||||
|
||||
This will run the perf tests for System.Collections.Tests.dll and output the results in results/System.Collections.Tests.dll-Linux.xml and results/System.Collections.Tests.dll-Linux.csv
|
||||
The results files will be dropped in corefx/bin/tests/FLAVOR/TESTLIBRARY/TARGETFRAMEWORK. The console output will also specify the location of these files.
|
||||
|
||||
Adding new Performance tests
|
||||
Adding New Performance Tests
|
||||
-----------
|
||||
Performance tests for CoreFX are built on top of xunit and [the Microsoft xunit-performance runner](https://github.com/Microsoft/xunit-performance/).
|
||||
Performance tests for CoreFX are built on top of xunit and [the Microsoft xunit-performance framework](https://github.com/Microsoft/xunit-performance/).
|
||||
|
||||
For the time being, perf tests should reside within their own "Performance" folder within the tests directory of a library (e.g. [corefx/src/System.IO.FileSystem/tests/Performance](https://github.com/dotnet/corefx/tree/master/src/System.IO.FileSystem/tests/Performance) contains perf tests for FileSystem).
|
||||
Performance tests should reside within their own "Performance" folder within the tests directory of a library (e.g. [corefx/src/System.IO.FileSystem/tests/Performance](https://github.com/dotnet/corefx/tree/master/src/System.IO.FileSystem/tests/Performance) contains perf tests for FileSystem).
|
||||
|
||||
Start by adding the following lines to the tests csproj:
|
||||
It's easiest to copy and modify an existing example like the one above. Notice that you'll need these lines in the tests csproj:
|
||||
```
|
||||
<ItemGroup>
|
||||
<!-- Performance Tests -->
|
||||
@@ -54,19 +36,12 @@ Start by adding the following lines to the tests csproj:
|
||||
</Compile>
|
||||
</ItemGroup>
|
||||
<!-- Optimizations to configure Xunit for performance -->
|
||||
<ItemGroup>
|
||||
<PropertyGroup>
|
||||
<IncludePerformanceTests>true</IncludePerformanceTests>
|
||||
</ItemGroup>
|
||||
</PropertyGroup>
|
||||
```
|
||||
(Replace Dictionary/List with whatever class you’re testing.)
|
||||
|
||||
Next, the project.json for the tests directory also needs to import the xunit libraries:
|
||||
|
||||
```
|
||||
"Microsoft.DotNet.xunit.performance": "1.0.0-*",
|
||||
"xunit": "2.1.0",
|
||||
"xunit.netcore.extensions": "1.0.0-prerelease-*"
|
||||
```
|
||||
Once that’s all done, you can actually add tests to the file.
|
||||
|
||||
Writing Test Cases
|
||||
|
||||
@@ -8,7 +8,7 @@ In a variety of situations, it's useful to run some code in another process. So
|
||||
- Being able to verify that things don't depend on state that's been configured previously, e.g. that some code you're calling doesn't require that some previous related code ran (e.g. that you can deserialize some state without it having previously been serialized in the same process)
|
||||
- Being able to test cross-process support for various things, e.g. cross-process synchronization, cross-process memory-mapped files, that file locking works correctly cross-process, cross-process communication via stdin/stdout/stderr, etc.
|
||||
|
||||
To achieve, this we use `RemoteInvoke` which is defined in `RemoteExecutorTestBase.cs`. It passes information about a static method to be executed and the arguments to be passed to it out to a spawned process that invokes the method. Lambdas / anonymous methods may be used, but they must not close over any state (including `this`); accidentally closing over state will likely result in strange errors. For additional information see https://github.com/dotnet/corefx/blob/master/src/Common/tests/System/Diagnostics/RemoteExecutorTestBase.cs and https://xunit.github.io/docs/running-tests-in-parallel.html
|
||||
To achieve, this we use `RemoteInvoke` which is defined in `RemoteExecutorTestBase.cs`. It passes information about a static method to be executed and the arguments to be passed to it out to a spawned process that invokes the method. Lambdas / anonymous methods may be used, but they must not close over any state (including `this`); accidentally closing over state will likely result in strange errors. For additional information see https://github.com/dotnet/corefx/blob/master/src/CoreFx.Private.TestUtilities/src/System/Diagnostics/RemoteExecutorTestBase.cs and https://xunit.github.io/docs/running-tests-in-parallel.html
|
||||
|
||||
Example (skipping additional usings):
|
||||
```cs
|
||||
|
||||
Reference in New Issue
Block a user