Tapir Liu - Go Optimizations 101 (2022/08/29)

Firstly, thanks to the whole Go community. An active and responsive community guarantees this book is finished in time.

Specially, I want to give thanks to the following people who helped me understand some implementation details in the official standard compiler and runtime: Keith Randall, Ian Lance Taylor, Axel Wagner, Cuong Manh Le, Michael Pratt, Jan Mercl, Matthew Dempsky, Martin Mhrmann, etc. I'm sorry if I forgot mentioning somebody in above lists. There are so many kind and creative gophers in the Go community that I must have missed out on someone.

I also would like to thank all gophers who ever made influences on the Go 101 book, be it directly or indirectly, intentionally or unintentionally.

Thanks to Olexandr Shalakhin for the permission to use one of the wonderful gopher icon designs as the cover image. And thanks to Renee French for designing the lovely gopher cartoon character.

Thanks to the authors of the following open source software and libraries used in building this book:

• golang, https://go.dev/
• gomarkdown, https://github.com/gomarkdown/markdown
• goini, https://github.com/zieckey/goini
• go-epub, https://github.com/bmaupin/go-epub
• pandoc, https://pandoc.org
• calibre, https://calibre-ebook.com/
• GIMP, https://www.gimp.org

Thanks the gophers who ever reported mistakes in this book or made corrections for this book:yingzewen,ivanburak,cortes-,skeeto@reddit,etc.

This book provides some code performance optimization tricks, tips, and suggestions.Most of the contents in this book are made based on the official standard Go compiler and runtime implementation.

Life is full of trade-offs, the programming world is, too.In programming, we often need to make trade-offs between code readability, maintainability, development efficiency, and program efficiency, etc.Even for one of the aspects, there are also trade-offs needing to be made.Taking program efficiency for an example, we might need to make trade-offs between memory saving, code execution speed, and implementation difficulty, etc.

In practice, most parts of the code base of a project don't need to be implemented with high performances. Keeping them maintainable and readable is often more important (than making them memory saving and run very fast).The suggestions made in this book are just for the code parts which implementations really need to be high performant.Some of the suggestions often lead to more verbose code.And please note that some of the suggested implementations might be only performant at some certain scenarios.

The contents in this book include:

• how to consume less CPU resources.
• how to consume less memory.
• how to make less memory allocations.
• how to control memory allocation places.
• how to reduce garbage collection pressure.

This book neither explains how to use performance analysis tools, such as pprof,nor tries to study deeply on compiler and runtime implementation details.None of the contents provided in this book make use of unsafe pointers and cgo.And the book doesn't talk about algorithms.In other words, this book tries to provide some optimization suggestionsin a way which is clear and easy to understand, for daily general Go programming.

Without particularly indicated, the code examples provided in this book are tested and run on a notebook with the following environment setup:

Some benchmark times information is removed from benchmark results to keep benchmark lines short.

Please note that:

• some of the talked suggestions in this book work on any platform and for any CPU models, but some others might only work on specified platforms and for specified CPU models. So please benchmark them on the same environments as your production environments before adopting any of them.
• some implementation details of the official standard Go compiler and runtime might change from version to version, which means some of the talked suggestions might not work for future Go toolchain versions.
• the book will be open sourced eventually since a later undetermined time point (about 2023/Jun), in a chapter by chapter way.

Tapir is the author of this book.He also wrote the Go 101 book.He is planning to write some other Go 101 series books.Please look forward to.

Tapir was ever (maybe will be again) an indie game developer.You can find his games here: tapirgames.com.

Welcome to improve this book by submitting corrections to Go 101 issue list (https://github.com/go101/go101) for all kinds of mistakes, such as typos, grammar errors, wording inaccuracies, wrong explanations, description flaws, code bugs, etc.

It is also welcome to send your feedback to the Go 101 twitter account: @go100and1 (https://twitter.com/go100and1).

In Go, a value of some kinds of types always contains only one part (in memory),whereas a value of other kinds of types might contain more than one part.If a value contains more than one part, then one of the parts is called the direct partand the others are called indirect parts. The direct part references the indirect parts.

If a value always contains only one part, then the part may be also called as the direct part of the value,and we say the value has no indirect parts.

In the official standard Go compiler implementation, each value of the following kinds of typesalways contains only one part:

• boolean types
• numeric types (int8, uint8, int16, uint16, int32, uint32, int64, uint64, int, uint, uintptr, float32, float64, complex64, complex128)
• pointer types
• unsafe pointer types
• struct types
• array types

And a value of the following kinds of types always may contain one or more indirect parts:

• slice types
• map types
• channel types
• function types
• interface types
• string types

When assigning/copying a value, only the direct part of the value is copied.After copying, the direct parts of the destination and source values both are referencing the indirect parts of the source value (if the indirect parts exist).

At run time, each value part is carried on one memory block (memory blocks will be explained in a following chapter).So, if a value contains two parts, the value is very possibly distributed on two memory blocks.

(Note: The terminology value part was invented by the Go 101 series books.It is not widely used in Go community.Personally, I think the terminology makes some conveniences when making some explanations.)

The size of a value part means how many bytes are needed to be allocated in memory to store the value part at run time.

The size of a value exactly equals to the size of the direct part of the value.In other words, the indirect parts of a value don't contribute to the size of the value.The reason? It has been mentioned above: when assigning/copying a value,only the direct part of the value is copied and the indirect parts might be shared by multiple values,so it is not a good idea to let the same indirect parts contribute to value sizes.

In the official standard Go compiler implementation, the sizes of all values of a specified type are all the same.So the same value size is also called as the size of that type.