You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Automated spellcheck for docs via GitHub Actions (and address all raised issues) (#2144)
* Add GH Action
* add cSpell Config
* Ignore team page
Mostly names
* capitalize GUID
* add some terms
* add known terms
* fix: "disassemblers"
* add known words
* ignore changelog
many names and many link to issues that will be copy/paste and could contain spelling errors
* more known terms
* Known terms.
* Fix: "priorities"
* fix: priorities
* known term
* add back-ticks
* fix: characteristic / minor grammar
* fix: variance
* add word
* back-ticks
* fix: "specify"
* back-ticks
* add terms
* front-matter ignore of configoptions
* back-ticks
* back-ticks
* add terms
* frontmatter ignore
Since term is only in front-matte
* fix: "log file"
* separate words from ignoreWords
* Fix branch for GH Action
* ignores of runstrategy in frontmatter
Copy file name to clipboardExpand all lines: docs/articles/configs/jobs.md
+15-4Lines changed: 15 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,9 +12,11 @@ Basically, a *job* describes how to run your benchmark. Practically, it's a set
12
12
There are several categories of characteristics which you can specify. Let's consider each category in detail.
13
13
14
14
### Id
15
+
15
16
It's a single string characteristic. It allows to name your job. This name will be used in logs and a part of a folder name with generated files for this job. `Id` doesn't affect benchmark results, but it can be useful for diagnostics. If you don't specify `Id`, random value will be chosen based on other characteristics
16
17
17
18
### Environment
19
+
18
20
`Environment` specifies an environment of the job. You can specify the following characteristics:
19
21
20
22
*`Platform`: `x86` or `x64`
@@ -41,7 +43,8 @@ It's a single string characteristic. It allows to name your job. This name will
41
43
BenchmarkDotNet will use host process environment characteristics for non specified values.
42
44
43
45
### Run
44
-
In this category, you can specifiy how to benchmark each method.
46
+
47
+
In this category, you can specify how to benchmark each method.
45
48
46
49
*`RunStrategy`:
47
50
*`Throughput`: default strategy which allows to get good precision level
@@ -61,16 +64,18 @@ In this category, you can specifiy how to benchmark each method.
61
64
Usually, you shouldn't specify such characteristics like `LaunchCount`, `WarmupCount`, `TargetCount`, or `IterationTime` because BenchmarkDotNet has a smart algorithm to choose these values automatically based on received measurements. You can specify it for testing purposes or when you are damn sure that you know the right characteristics for your benchmark (when you set `TargetCount` = `20` you should understand why `20` is a good value for your case).
62
65
63
66
### Accuracy
67
+
64
68
If you want to change the accuracy level, you should use the following characteristics instead of manually adjusting values of `WarmupCount`, `TargetCount`, and so on.
65
69
66
70
*`MaxRelativeError`, `MaxAbsoluteError`: Maximum acceptable error for a benchmark (by default, BenchmarkDotNet continue iterations until the actual error is less than the specified error). *In these two characteristics*, the error means half of 99.9% confidence interval. `MaxAbsoluteError` is an absolute `TimeInterval`; doesn't have a default value. `MaxRelativeError` defines max acceptable (`(<half of CI 99.9%>) / Mean`).
67
71
*`MinIterationTime`: Minimum time of a single iteration. Unlike `Run.IterationTime`, this characteristic specifies only the lower limit. In case of need, BenchmarkDotNet can increase this value.
68
72
*`MinInvokeCount`: Minimum about of target method invocation. Default value if `4` but you can decrease this value for cases when single invocations takes a lot of time.
69
-
*`EvaluateOverhead`: if you benchmark method takes nanoseconds, BenchmarkDotNet overhead can significantly affect measurements. If this characterics is enable, the overhead will be evaluated and subtracted from the result measurements. Default value is `true`.
73
+
*`EvaluateOverhead`: if your benchmark method takes nanoseconds, BenchmarkDotNet overhead can significantly affect measurements. If this characteristic is enabled, the overhead will be evaluated and subtracted from the result measurements. Default value is `true`.
70
74
*`WithOutlierMode`: sometimes you could have outliers in your measurements. Usually these are unexpected outliers which arose because of other processes activities. By default (`OutlierMode.RemoveUpper`), all upper outliers (which is larger than Q3) will be removed from the result measurements. However, some of benchmarks have *expected* outliers. In these situation, you expect that some of invocation can produce outliers measurements (e.g. in case of network activities, cache operations, and so on). If you want to see result statistics with these outliers, you should use `OutlierMode.DontRemove`. If you can also choose `OutlierMode.RemoveLower` (outliers which are smaller than Q1 will be removed) or `OutlierMode.RemoveAll` (all outliers will be removed). See also: @BenchmarkDotNet.Mathematics.OutlierMode
71
-
*`AnalyzeLaunchVariance`: this characteristic makes sense only if `Run.LaunchCount` is default. If this mode is enabled and, BenchmarkDotNet will try to perform several launches and detect if there is a veriance between launches. If this mode is disable, only one launch will be performed.
75
+
*`AnalyzeLaunchVariance`: this characteristic makes sense only if `Run.LaunchCount` is default. If this mode is enabled and, BenchmarkDotNet will try to perform several launches and detect if there is a variance between launches. If this mode is disable, only one launch will be performed.
72
76
73
77
### Infrastructure
78
+
74
79
Usually, you shouldn't specify any characteristics from this section, it can be used for advanced cases only.
75
80
76
81
*`Toolchain`: a toolchain which generates source code for target benchmark methods, builds it, and executes it. BenchmarkDotNet has own toolchains for .NET, .NET Core, Mono and CoreRT projects. If you want, you can define own toolchain.
@@ -121,18 +126,24 @@ Basically, it's a good idea to start with predefined values (e.g. `EnvMode.RyuJi
121
126
122
127
Note that the job cannot be modified after it's added into config. Trying to set a value on property of the frozen job will throw an `InvalidOperationException`. Use the `Job.Frozen` property to determine if the code properties can be altered.
123
128
124
-
If you do want to create a new job based on frozen one (all predefined job values are frozen) you can use the `.With()` extension method
129
+
If you do want to create a new job based on frozen one (all predefined job values are frozen) you can use the `.With()` extension method
130
+
125
131
```cs
126
132
varnewJob=Job.Dry.With(Platform.X64);
127
133
```
134
+
128
135
or pass the frozen value as a constructor argument
Copy file name to clipboardExpand all lines: docs/articles/configs/validators.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,12 +5,12 @@ name: Validators
5
5
6
6
# Validators
7
7
8
-
A **validator** can validate your benchmarks before they are executed and produce validation errors.
9
-
If any of the validation errors is critical, then none of the benchmarks will get executed.
8
+
A **validator** can validate your benchmarks before they are executed and produce validation errors.
9
+
If any of the validation errors is critical, then none of the benchmarks will get executed.
10
10
11
11
Available validators are:
12
12
13
13
*`BaselineValidator.FailOnError` - it checks if more than 1 Benchmark per class has `Baseline = true` applied. This validator is mandatory.
14
-
*`JitOptimizationsValidator.(Dont)FailOnError` - it checks whether any of the referenced assemblies is non-optimized. DontFailOnError version is enabled by default.
14
+
*`JitOptimizationsValidator.(Dont)FailOnError` - it checks whether any of the referenced assemblies is non-optimized. `DontFailOnError` version is enabled by default.
15
15
*`ExecutionValidator.(Dont)FailOnError` - it checks if it is possible to run your benchmarks by executing each of them once. Optional.
16
16
*`ReturnValueValidator.(Dont)FailOnError` - it checks if non-void benchmarks return equal values. Optional.
- Install [Mono version 5 or higher](https://www.mono-project.com/download/stable/#download-mac)
@@ -40,15 +40,15 @@ After you have installed these pre-requisites, you can build the BenchmarkDotNet
40
40
41
41
Build has a number of options that you use. Some of the more important options are
42
42
43
-
-**skiptests** - do not run the tests. This can shorten build times quite a bit. On Windows: `.\build.ps1 --SkipTests=True` or `./build.sh --skiptests=true` on Linux/macOS.
43
+
-**`skiptests`** - do not run the tests. This can shorten build times quite a bit. On Windows: `.\build.ps1 --SkipTests=True` or `./build.sh --skiptests=true` on Linux/macOS.
44
44
45
-
-**configuration** - build the 'Release' or 'Debug' build type. Default value is 'Release'. On Windows: `.\build.ps1 -Configuration Debug` or `./build.sh --configuration debug` on Linux/macOS.
45
+
-**`configuration`** - build the 'Release' or 'Debug' build type. Default value is 'Release'. On Windows: `.\build.ps1 -Configuration Debug` or `./build.sh --configuration debug` on Linux/macOS.
46
46
47
-
-**target** - with this parameter you can run a specific target from build pipeline. Default value is 'Default' target. On Windows: `.\build.ps1 -Target Default` or `./build.sh --target default` on Linux/macOS. Available targets:
48
-
-**Default** - run all actions one by one.
49
-
-**Clean** - clean all `obj`, `bin` and `artifacts` directories.
50
-
-**Restore** - automatically execute `Clean` action and after that restore all NuGet dependencies.
51
-
-**Build** - automatically execute `Restore` action, then run MSBuild for the solution file.
52
-
-**FastTests** - automatically execute `Build` action, then run all tests from the BenchmarkDotNet.Tests project.
53
-
-**SlowTests** - automatically execute `Build` action, then run all tests from the BenchmarkDotNet.IntegrationTests project.
54
-
-**Pack** - automatically execute `Build` action and after that creates local NuGet packages.
47
+
-**`target`** - with this parameter you can run a specific target from build pipeline. Default value is 'Default' target. On Windows: `.\build.ps1 -Target Default` or `./build.sh --target default` on Linux/macOS. Available targets:
48
+
-**`Default`** - run all actions one by one.
49
+
-**`Clean`** - clean all `obj`, `bin` and `artifacts` directories.
50
+
-**`Restore`** - automatically execute `Clean` action and after that restore all NuGet dependencies.
51
+
-**`Build`** - automatically execute `Restore` action, then run MSBuild for the solution file.
52
+
-**`FastTests`** - automatically execute `Build` action, then run all tests from the BenchmarkDotNet.Tests project.
53
+
-**`SlowTests`** - automatically execute `Build` action, then run all tests from the BenchmarkDotNet.IntegrationTests project.
54
+
-**`Pack`** - automatically execute `Build` action and after that creates local NuGet packages.
Copy file name to clipboardExpand all lines: docs/articles/contributing/disassembler.md
+1-2Lines changed: 1 addition & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,11 +13,10 @@ We have 3 disassemblers:
13
13
The MonoDisassembler is very simple: it spawns Mono with the right arguments to get the asm, Mono prints the output to the console and we just parse it. Single class does the job: `MonoDisassembler`.
14
14
15
15
When it comes to Windows disassemblers it's not so easy. To obtain the disassm we are using ClrMD. ClrMD can attach only to the process of same bitness (architecture).
16
-
This is why we have two dissasemblers: x64 and x86. The code is the same (single class, linked in two projects) but compiled for two different architectures. We keep both disassemblers in the resources of the BenchmarkDotNet.dll. When we need the disassembler, we search for it in the resources, copy it to the disk and run (it's an exe).
16
+
This is why we have two disassemblers: x64 and x86. The code is the same (single class, linked in two projects) but compiled for two different architectures. We keep both disassemblers in the resources of the BenchmarkDotNet.dll. When we need the disassembler, we search for it in the resources, copy it to the disk and run (it's an exe).
17
17
18
18
On Linux it's simpler (only x64 is supported) and we don't spawn a new process (everything is done in-proc).
19
19
20
-
21
20
### How to debug the disassembler
22
21
23
22
You need to create a new console app project which executes the code that you would like to disassemble. In this app, you need to run the desired code (to get it jitted) and just don't exit before attaching the disassembler and getting the disassembly.
Copy file name to clipboardExpand all lines: docs/articles/features/etwprofiler.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,5 @@
1
1
---
2
+
#cspell:ignore etwprofiler
2
3
uid: docs.etwprofiler
3
4
name: EtwProfiler
4
5
---
@@ -60,7 +61,6 @@ class Program
60
61
61
62
* Passing `-p ETW` or `--profiler ETW` command line argument to `BenchmarkSwitcher`
62
63
63
-
64
64
## Configuration
65
65
66
66
To configure the new diagnoser you need to create an instance of `EtwProfilerConfig` class and pass it to the `EtwProfiler` constructor. The parameters that `EtwProfilerConfig` ctor takes are:
0 commit comments