dgryski/go-perfbook

Thoughts on Go performance optimization

go-perfbook

This document outlines best practices for writing high-performance Go code.

The first sections cover writing optimized code in any language. The later sections cover Go-specific techniques.

Multiple Language Versions

• English
• 中文
• Español
• Português Brasileiro

Table of Contents

1. Writing and Optimizing Go code
2. How to Optimize
   1. Optimization Workflow
   2. Concrete Optimization Tips
3. Data Changes
4. Algorithmic Changes
5. Benchmark Inputs
6. Program Tuning
7. Optimization Workflow Summary
8. Garbage Collection
9. Runtime and Compiler
10. Unsafe
11. Common gotchas with the standard library
12. Alternate Implementations
13. CGO
14. Advanced Techniques
15. Assembly
16. Optimizing an Entire Service
17. Tooling
    1. Profiling
    2. Tracer
18. Appendix
    1. Implementing Research Papers

Contributing

This is a work-in-progress book in Go performance.

There are different ways to contribute:

1. add to or summarizes the resources in TODO
2. add bullet points or new topics to be covered
3. write prose and flesh out the sections in the book

Eventually sample programs to optimize and exercises will be needed (maybe).

Coordination will be done in the #performance channel on the Gophers slack.

go-perfbook's Issues

[WIP]Traditional Chinese Version

I would like to help translate it into traditional Chinese version

zero only part of an array, rather than the whole thing

This sentence zero only part of an array, rather than the whole thing is really hard to understand for me. Can you describe more or change another way to say it?

I know what "pay only for what you use, not what you could have used" mean. Just don't get it what the "zero" means. It's a verb or noun?

Spanish version

Hi! I'm interested in beginning translating the project into Spanish as well and I was wondering if I could start pull requests of the files. Many thanks in advance!

[WIP] Korean version

I’d like to begin translating this docs to korean. I’ll send a PR when done :)

Thanks.

Worry about O(1)

When outlining big-O notation, you describe O(1) as

O(1): a field access, array or map lookup

Advice: don't worry about it

But similarly to O(n), O(1) algorithms can differ in performance quite wildly. You note that O(n) has a constant factor, but I would note this about O(1) as well, because once we have O(1) in a hot loop, we're essentially solving an O(n) problem.

What I'm getting at is that map lookup involving hashing a value is an order of magnitude (or more) slower than an array lookup, which involves just a bit of pointer chasing. I did some very basic benchmarking (n=1) a while ago, but the gist of it should hold, more or less (I didn't really worry about caches, branch predictions etc.).

Add Go's GC guide

https://tip.golang.org/doc/gc-guide

Use `ctx.Done()` instead of `time.NewTimer()` as a replacement of `time.After()`?

Hi there!

Regarding this suggestion:

time.After() leaks until it fires; use t := NewTimer(); t.Stop() / t.Reset()

AFAIK, I'm afraid time.NewTimer() is also difficult to use correctly.

How about using ctx.Done() as a replacement of time.After()?

For example, instead of doing this:

select {
case value := <-C:
	// handle value
case <-time.After(5 * time.Second):
	// timeout elapses
}

Maybe we should do this:

ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

select {
case value := <-C:
	// handle value
case <-ctx.Done():
	// timeout elapses
}

Testing to ensure upper bound for heap allocations

go-perfbook already explains how reducing heap allocations is a way to speed up execution and reduce GC delays, etc. I noticed, through example code from another developer, that it is possible to write tests such that one can effectively ensure a certain bound on heap allocations. This may be helpful for code/libraries that want to ensure/guarantee a low allocation count in specialized libraries, as well as prove that performance does not degrade (without noticing) over time due to changes in own code, Go standard library or run-time.

The test TestAllocations illustrates this.

Brazilian Portuguese (pt-BR) version

I am starting to work on the Brazilian Portuguese version.

Would you prefer taking a PR when the first sections are done or only when the whole document is completed?

Video missing

This link is broken.

https://www.youtube.com/watch?time_continue=429&v=RT46MpK39rQ

"unrolling still effective" sample code not working

https://play.golang.org/p/6tnySwNxG6O

Divide the parts of the book in 3 sections

Hi all.
I see the paragraph:

This book is split into different sections:

• Basic tips for writing not-slow software
  • CS 101-level stuff
• Tips for writing fast software
  • Go-specific sections on how to get the best from Go
• Advanced tips for writing really fast software
  • For when your optimized code isn't fast enough

But, I do not know how to divide the parts of the book in 3 sections above.