Top 4.7% dependent repos on proxy.golang.org
proxy.golang.org : github.com/akutz/lem
Package lem provides a comment-driven approach for writing benchmarks that assert when values leak, escape, and move to the heap, as well as the number of allocations and memory as a result. Callers may define benchmark functions with the following signature: The functions can then be annotated with comments that are parsed by the lem test harness, β. These comments all begin the same way: The <ID> is a unique ID that can be any value a developer wishes it to be, and the value is used for two purposes: 1. The <ID> is a key in the map β.Benchmarks and points to the actual benchmark function for that <ID>. 2. The <ID> is used to group all associated "lem.<ID>"" comments. There are two types of comments: 1. Those placed above the function signature 2. Those placed alongside lines inside the function The first comment occurs above the function signature and defines the test's name, the value used as the argument for the "name" parameter in the "Run" function for the types "testing.T" and "testing.B". The comment takes the form "lem.<ID>.name=<NAME>". The <ID> and <NAME> values are used to build the test's path string: The path string is then split with "/" as the separator. The following are examples of valid forms of "lem.<ID>.name=<NAME>": The above comments translate to the following strings: The next comment also occurs above the function's signature and takes the form "lem.<ID>.alloc=<VALUE>" or "lem.<ID>.alloc=<MIN>-<MAX>". This comment asserts the number of allocations expected to occur during the execution of the benchmark. The number may be exact or an inclusive range. Examples include: The first example asserts a single allocation should occur while the second example asserts either two, three, or four allocations are expected to have occurred. The next comment also occurs above the function's signature and takes the form "lem.<ID>.bytes=<VALUE>" or "lem.<ID>.bytes=<MIN>-<MAX>". This comment asserts the number of bytes expected to be allocated during the execution of the benchmark. For more documentation please refer to "lem.<ID>.alloc" as both comments have the same format rules. The next comment occurs alongside a line inside of a function, and it is "lem.<ID>.m=<REGEX>". This comment asserts that the Go compiler's optimization flag "-m" should emit some type of message for the line of code where the comment appears, ex. The above code is on line 70 of a source file named escape.go, and the comment asserts the output from "go build -gcflags -m" should match the regex "escape.go:70:\d+: x escapes to heap". Please note that special characters must be escaped, such as "new\(int32\) escapes to heap". The last comment is a variant of the previous and takes the form "lem.<ID>.m!=<REGEX>". This comment asserts a provided pattern should not match the compiler optimization output. This is useful when you want to assert a variable did not escape, leak, or move. For example: The above comment asserts none of the words "escape", "leak", or "move" appeared in the compiler optimization output for line 80 for the source file in which the comment exists.
Registry
-
Source
- Documentation
- JSON
- codemeta.json
purl: pkg:golang/github.com/akutz/lem
License: Apache-2.0
Latest release: almost 4 years ago
First release: almost 4 years ago
Namespace: github.com/akutz
Dependent repositories: 1
Stars: 72 on GitHub
Forks: 2 on GitHub
See more repository details: repos.ecosyste.ms
Last synced: 25 days ago