"A Journey With Go" is an illustration by Renee French based on the original Go Gopher.
i️ This article is based on Go 1.13.
The go test command provides many excellent features such as code coverage, CPU, and memory analysis. To provide these statistics, Go needs a way to track CPU usage, or when a function is used in a code override.
This article is a GCTT translation organized by go language Chinese network, published in the Go language Chinese network public account, reprint please contact us for authorization.
<h1 class="pgc-h-arrow-right" data-track="5" > performance measurements</h1>
Go uses several ways to generate these statistics:
Dynamically insert performance measurement statements so that they can track when code enters a function or condition. This strategy is used in code coverage[1].
Record multiple program samples per second. This strategy is used in CPU analysis[2].
Use static hooks in your code to call the required functions during execution. This strategy is used in memory analysis.
Let's write a simple program and review everything. Here's the code we'll use in later chapters:
main.go hosted on [GitHub] (https://github.com/) View[3]
<h1 class="pgc-h-arrow-right" data-track="13" > code coverage</h1>
With the SSA code generated by the GOSSAFUNC=run Go test -cover command, we can see what changes Go has made to the program:
The variable GoCover_0_313837343662366134383538 is an array of flags where each key is a block of code, and the corresponding flag is set to 1 when the code actually enters this block.
You can find more information about SSA in my article "Go: Compiler Phases"[4].
The generated code will be used later in the function that manages the code coverage report. We can verify this by overwriting the object file generated during disassembly code with the objdump command. Running go test -cover -o main.o && Go tool objdump main.go will disassemble the code and display the missing parts. It first initializes and registers coverage in the auto-generated init function:
Test.go added the init method
Then, as mentioned earlier, the test collects coverage data during execution and triggers a method to actually write and display coverage:
Go test calls the after function
<h1 class="pgc-h-arrow-right" data-track="24" > CPU analysis</h1>
The strategy for tracking CPU usage is different. Go stops the program and collects a sample of the running program. Here is the trace of the code without CPU profiling enabled:
Here is the trace of the same code that enables CPU profiling:
The increased trace is related to pprof and performance analysis. Here's a zoomed-in view of one of them:
The profileWriter method is called in a loop, collecting CPU data every 100 milliseconds to finally generate a report at the end of the performance analysis.
<h1 class="pgc-h-arrow-right" data-track="29" > memory analysis</h1>
Memory analysis is included in the source code and is integrated into the memory allocation system. With -memprofile to enable memory profiling[5], a memory allocator located in malloc.go[6] will analyze the allocated memory.[7] Here, it can still be verified by disassembly code. Here is the use of the memory allocator:
Enable memory allocation analysis
You can find more information about test packages in my article "Go: Unknown Parts of the Test Package[8]".
street : https://medium.com/a-journey-with-go/go-instrumentation-in-go-e845cdae0c51
Author: Vincent Blanchon[9] Translator: krystollia[10] Proofreader: polaris1119[11]
This article is compiled by GCTT[12], Go Chinese.com[13] honored launch, published in the Go language Chinese network public number, reprint please contact us for authorization.
<h1 class="pgc-h-arrow-right" data-track="36" > references</h1>
[1]
Code coverage: https://golang.org/doc/go1.2#cover
[2]
CPU analysis: https://blog.golang.org/profiling-go-programs
[3]
GitHub] (https://github.com/) [View: https://gist.github.com/blanchonvincent/d4ed01d31b3ed99eb5cd87629ecfe926/raw/1fbac76f932d020a2b172b2385fb1cda69b83b1e/main.go
[4]
“Go: Compiler Phases”: https://medium.com/@blanchon.vincent/go-compiler-phases-4e5a153ca889
[5]
Enable memory profiling: https://github.com/golang/go/blob/release-branch.go1.13/src/cmd/compile/internal/gc/util.go#L55-L77
[6]
malloc.go: https://github.com/golang/go/blob/release-branch.go1.13/src/runtime/malloc.go#L877
[7]
Analyze allocated memory: https://github.com/golang/go/blob/release-branch.go1.13/src/runtime/malloc.go#L1097-L1105
[8]
Go: Unknown Parts of the Test Package: https://medium.com/a-journey-with-go/go-unknown-parts-of-the-test-package-df8988b2ef7f
[9]
Vincent Blanchon - https://medium.com/@blanchon.vincent
[10]
krystollia: https://github.com/krystollia
[11]
polaris1119: https://github.com/polaris1119
[12]
GCTT: https://github.com/studygolang/GCTT
[13]
Go Chinese: https://studygolang.com/