Go Optimizations 101 (2022/08/29)

Acknowledgments
About Go Optimizations 101
	About the author
	Feedback
Value Parts and Value Sizes
	Values and value parts
	Value/type sizes
	Detailed type sizes
	Memory alignments
	Struct padding
	Value copy costs and small-size types/values
	Value copy scenarios
Memory Allocations
	Memory blocks
	Memory allocation places
	Memory allocation scenarios
	Memory wasting caused by allocated memory blocks larger than needed
	Reduce memory allocations and save memory
	Avoid unnecessary allocations by allocating enough in advance
	Avoid allocations if possible
	Save memory and reduce allocations by combining memory blocks
	Use value cache pool to avoid some allocations
Stack and Escape Analysis
	Goroutine stacks
	Escape analysis
		Escape analysis examples
	Stack frames of function calls
	Stacks growth and shrinkage
	Memory wasting caused by unused stack spaces
	For all kinds of reasons, a value (part) will escape to heap even if it is only used in one goroutine
		A local variables declared in a loop will escape to heap if it is referenced by a value out of the loop
		The value parts referenced by an argument will escape to heap if the argument is passed to interface method calls
		A reflect.ValueOf function call makes the values referenced by its argument escape to heap
		The values referenced by function return results will escape
	Function inline might affect escape analysis results
		Function inlining is not always helpful for escape analysis
	Control memory block allocation places
		Ensure a value is allocated on heap
		Use explicit value copies to help compilers detect some values don\'t escape
		Memory size thresholds used by the compiler to make allocation placement decisions
		Use smaller thresholds
		Allocate the backing array of a slice on stack even if its size is larger than or equal to 64K (but not larger than 10M)
		Allocate the backing array of a slice with an arbitrary length on stack
		More tricks to allocate arbitrary-size values on stack
	Grow stack in less times
Garbage Collection
	GC pacer
	Automatic GC might affect Go program execution performance
	How to reduce GC pressure?
	Memory fragments
	Memory wasting caused by sharing memory blocks
	Try to generate less short-lived memory blocks to lower automatic GC frequency
	Use new heap memory percentage strategy to control automatic GC frequency
	Since Go toolchain 1.18, the larger GC roots, the larger GC cycle intervals
	Use memory ballasts to avoid frequent GC cycles
	Use Go toolchain 1.19 introduced memory limit strategy to avoid frequent GC cycles
Pointers
	Avoid unnecessary nil array pointer checks in a loop
		The case in which an array pointer is a struct field
	Avoid unnecessary pointer dereferences in a loop
Structs
	Avoid accessing fields of a struct in a loop though pointers to the struct
	Small-size structs are optimized specially
	Make struct size smaller by adjusting field orders
Arrays and Slices
	Avoid using literals of large-size array types as comparison operands
	Using slice-to-array-pointer conversions introduced in Go 1.17 to copy slices
	The make and append builtin function implementations
	Try to clip the first argument of an append call if we know the call will allocate
	Grow slices (enlarge slice capacities)
	Try to grow a slice in one step
	Clone slices
	Merge two slices
	Merge more than two slices (into a new slice)
	Insert a slice into another one
	Don\'t use the second iteration variable in a for-range loop if high performance is demanded
	Reset all elements of an array or slice
	Specify capacity explicitly in subslice expression
	Use index tables to save some comparisons
String and Byte Slices
	Conversions between strings and byte slices
		A string-to-byte-slice conversion following the range keyword doesn\'t allocate
		A byte-slice-to-string conversion appearing as a comparison operand doesn\'t allocate
		A byte-slice-to-string conversion appearing as the index key of a map element retrieval expression doesn\'t allocate
		A byte-slice-to-string conversion appearing as an operand in a string concatenation expression doesn\'t allocate if at least one of concatenated operands is a non-blank string constant
		If the result of an operation is a stirng or byte slice, and the length of the result is larger than 32, then the byte elements of the result will be always allocated on heap
	Efficient ways to concatenate strings
		The strings.Builder way might waste some memory sometimes
		Use byte slice to concatenate strings
	Merge a string and a byte slice into a new byte slice
	The strings.Compare function is not very performant now
	Avoid allocations if possible
BCE (Bound Check Eliminate)
	Example 1
	Example 2
	Example 3
	Example 4
	Sometimes, the compiler needs some hints to remove some bound checks
	Write code in BCE-friendly ways
	The current official standard Go compiler fails to eliminate some unnecessary bound checks
Maps
	Clear map entries
	aMap[key]++ is more efficient than aMap[key] = aMap[key] + 1
	Pointers in maps
	Using byte arrays instead of short strings as keys
	Lower map element modification frequency
	Try to grow a map in one step
	Use index tables instead of maps which key types have only a small set of possible values
Channels
	Programming with channels is fun but channels are not the most performant way for some use cases
	Use one channel instead of several ones to avoid using select blocks
	Try-send and try-receive select code blocks are specially optimized
Functions
	Function inlining
		Which functions are inline-able?
		A call to a function value is not inline-able if the value is hard to be determined at compile time
		The go:noinline comment directive
		Write code in the ways which are less inline costly
		Make hot paths inline-able
		Manual inlining is often more performance than auto-inlining
		Inlining might do negative impact on performance
	Pointer parameters/results vs. non-pointer parameters/results
	Named results vs. anonymous results
	Try to store intermediate calculation results in local variables
	Avoid deferred calls in loops
	Avoid using deferred calls if extreme high performance is demanded
	The arguments of a function call will be always evaluated when the call is invoked
	Try to make less values escape to heap in the hot paths
Interfaces
	Box values into and unbox values from interfaces
	Try to void memory allocations by assigning interface to interface
	Calling interface methods needs a little extra cost
	Avoid using interface parameters and results in small functions which are called frequently