-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[benchmark] Naming Convention #20334
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
b4f901b
[benchmark] Naming Convention
palimondo bc0064d
[benchmark] Simpler naming convention regex
palimondo e828adc
[benchmark] Naming: emphasize ABBR are last resort
palimondo 9857b0d
[benchmark] Replace OCB with Bridging
palimondo 419ec8b
[benchmark] Use for ISO 639-3 language variants
palimondo File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,151 @@ | ||
# Naming Convention | ||
|
||
Historically, benchmark names in the Swift Benchmark Suite were derived from the | ||
name of the `runFunction`, which by convention started with prefix `run_`, | ||
followed by the benchmark name. Therefore most of the legacy benchmark names | ||
conform to the [`UpperCamelCase`](http://bit.ly/UpperCamelCase) convention. | ||
After introduction of | ||
[`BenchmarkInfo`](https://github.com/apple/swift/pull/12048) | ||
to describe the benchmark metadata, names can be any string. To create more | ||
cohesive and well structured system, names of newly added benchmarks should meet | ||
the following set of requirements: | ||
|
||
<ul> | ||
<li> | ||
<!-- The <li> content with <details> is pre-formatted as HTML, to work around | ||
Markdown renderer interrupting the paragraph, which creates an ugly gap. --> | ||
<strong>Letters, numbers and dots.</strong> Start with short unique name in | ||
<code>UpperCamelCase</code>. | ||
For a family of benchmarks, separate the name components with periods. | ||
<details> | ||
|
||
Very long compound names using `UpperCamelCase` are hard to read. Use `.` to | ||
increase readability and structure. | ||
|
||
Prefer unique and creative name to nondescript generic term, unless the | ||
benchmark is testing individual method on a concrete type. | ||
|
||
```` | ||
⛔️ Dictionary2 | ||
✅ AngryPhonebook | ||
✅ Dictionary.AnyHashable.String.update | ||
✅ Array.append.Array.Int | ||
```` | ||
|
||
Benchmark names are used to run individual tests when passed as command line | ||
arguments to the benchmark driver. Stick to ASCII letters, numbers and period. | ||
Exceptionally: | ||
|
||
* Use **`-`** only to denote control flow constructs like `for-in` or `if-let`. | ||
* Use **`!`** and **`?`** for optional types, conditional or forced downcasting, | ||
optional chaining etc. | ||
|
||
```` | ||
✅ Array.append.Array.Int? | ||
✅ Flatten.Array.Tuple4.for-in.reserved | ||
✅ Bridging.NSArray.as!.Array.NSString | ||
```` | ||
|
||
Note: Special characters that could be interpreted by the shell require escaping | ||
(`\!`) or quoting the name, when running such benchmarks individually. | ||
|
||
</details><p><!-- spacer --></p></li> | ||
<li> | ||
<strong>Use groups and variants</strong> to structure the benchmark family by | ||
degrees of freedom (e.g. different types implementing a protocol, value vs. | ||
reference types etc.). Use <strong>numbered suffixes</strong> to denote | ||
differently sized variants. | ||
<details> | ||
|
||
Benchmarks in a family can be grouped by the tested operation, method or varied | ||
by types and different workload sizes. It might be necessary to abbreviate some | ||
names to fit the size limit, based on the longest combination. Choose consistent | ||
names for the components throughout all members in the family, to allow for | ||
relative comparison across the different axis of variation. | ||
|
||
```` | ||
✅ Seq.dropFirst.Array | ||
✅ Seq.dropLast.Range.lazy | ||
✅ Seq.dropWhile.UnfoldSeq | ||
✅ Seq.prefix.AnySeq.RangeIter.lazy | ||
✅ Seq.prefixWhile.AnyCol.Array | ||
✅ Seq.suffix.AnySeq.UnfoldSeq.lazy | ||
|
||
✅ Existential.Array.ConditionalShift.Ref1 | ||
✅ Existential.Array.Mutating.Ref2 | ||
✅ Existential.Array.method.1x.Ref3 | ||
✅ Existential.Array.method.2x.Ref4 | ||
✅ Existential.Array.Shift.Val0 | ||
✅ Existential.MutatingAndNonMutating.Val1 | ||
✅ Existential.Mutating.Val2 | ||
✅ Existential.method.1x.Val3 | ||
✅ Existential.method.2x.Val4 | ||
✅ Existential.Pass2.method.1x.Ref1 | ||
✅ Existential.Pass2.method.2x.Ref2 | ||
|
||
✅ Set.isSubset.Int25 | ||
✅ Set.symmetricDifference.Int50 | ||
```` | ||
|
||
</details><p><!-- spacer --></p></li> | ||
<li> | ||
<strong>Groups and types are <code>UpperCase</code>, methods are | ||
<code>lowerCase</code>.</strong> | ||
<details> | ||
|
||
Use periods to separate the name components in variants derived from specialised | ||
generic types or significant method chains. | ||
|
||
```` | ||
⛔️ InsertCharacterTowardsEndIndexNonASCII | ||
```` | ||
|
||
There's no need to be literal with type names. **Be descriptive**: | ||
|
||
```` | ||
✅ String.insert.EmojiChar.NearEnd | ||
✅ String.insert.ASCIIChar.StartIndex | ||
✅ Flatten.Array.Tuple4.lazy.flatMap | ||
```` | ||
|
||
</details><p><!-- spacer --></p></li> | ||
<li> | ||
<strong>Keep it short.</strong> 40 characters at most. Abbreviate if necessary. | ||
<details> | ||
|
||
Benchmarking results are reported on GitHub and very long names are causing | ||
horizontal table scrolling which unfortunately obscures the columns with actual | ||
measurements. Fixed upper size limit also helps with the formatted console | ||
output, when measuring locally. *It is more important for benchmark's name to be | ||
unique and short, than overly descriptive.* | ||
|
||
Prefer concise names for potential benchmark family extensions. Leave out the | ||
nested types from variants if they aren't strictly necessary for disambiguation. | ||
If there's potentially valuable future variant, like testing `ContiguousArray`, | ||
keep the `Array` now, allowing for addition of `ContArr` variants later. | ||
|
||
Use **`Val`** and **`Ref`** as short descriptors for variants that compare value | ||
types (`struct`, `Int`) with reference types (often named with `Class` in the | ||
legacy-style). | ||
Prefer **`Char`** to `Character`, which can be combined with codepage or | ||
language prefix/suffix when necessary (`EmojiChar`, `ASCIIChar`). For benchmarks | ||
that measure `String`'s Unicode performance for various languages, use | ||
the [three letter codes](https://en.wikipedia.org/wiki/ISO_639-3) instead of | ||
spelling out the whole language names. | ||
|
||
When necessary, use *consistent* abbreviations like `Str` and `Arr` within the | ||
benchmark family, to fit a system with descriptive names into 40 characters: | ||
|
||
```` | ||
✅ Bridging.NSDict.as!.Dict.NSString.NSNum | ||
✅ Seq.prefixWhile.AnySeq.UnfoldSeq.lazy | ||
```` | ||
|
||
As a last resort, use *numbered suffixes* to disambiguate between benchmarks | ||
with minor implementation variations. | ||
|
||
</details></li> | ||
</ul> | ||
|
||
Technically, the benchmark's name must match the following regular expression: | ||
`[A-Z][a-zA-Z0-9\-.!?]+` |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.