diff options
author | Bill Wert <billwert@microsoft.com> | 2017-05-01 06:27:30 +0300 |
---|---|---|
committer | Bill Wert <billwert@microsoft.com> | 2017-05-01 06:29:05 +0300 |
commit | fa8a38b3128617b3e274651d4e1acce3d4d94c5a (patch) | |
tree | 9ed30860e2408f13edcd5971b5c39df4a254532c /Documentation | |
parent | f2e9d908ccd6f11f601610cc8870e030d4133c0c (diff) |
Update guidance to include special types
I noticed a handful of tests substituting int for a value type, which
does not always do what you might want. In general test authors should
consider if the codepath being tested has optimizations around built-in
data types or get faster if types implement certain interfaces.
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/project-docs/performance-tests.md | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/Documentation/project-docs/performance-tests.md b/Documentation/project-docs/performance-tests.md index 635e32a8bf..b39b73a508 100644 --- a/Documentation/project-docs/performance-tests.md +++ b/Documentation/project-docs/performance-tests.md @@ -107,6 +107,8 @@ Test cases should adhere to the following guidelines, within reason: * There are two main ways to detect when a test case is being "optimized out": * Look at the disassembly of the function (with the Visual Studio disassembler, for example). * Observe unusual changes in the duration metric. If your test suddenly takes 1% of its previous time, odds are something has gone wrong. +* Before using intrinsic data types (int, string, etc) to represent value and reference types in your test, consider if the code under test is optimized for those types versus normal classes and structs. + * Also consider interfaces. For example, methods on ```List<T>``` using equality will be much faster on Ts that implement ```IEquatable<T>```. Avoid the following performance test test anti-patterns: * Tests for multiple methods which all end up calling the same final overload. This just adds noise and extra duplicate data to sift through. |