M0111 heap allocation
marmot build -allocs lists where the program allocates on the heap and why the object could not live in the frame: it is returned, stored in memory that outlives the function or in a global, passed to a call that may keep it, captured by an escaping closure, converted to an interface, kept across loop iterations, or too large for the frame.
Heap allocations cost time in the allocator and the garbage collector; those in loops cost on every iteration.
The mistake and the fix
func newPoint() *Point {
return &Point{1, 2} // returned: heap
}func point() Point {
return Point{1, 2} // a value: no allocation
}The fix
Return values instead of pointers, pass buffers in, keep large arrays out of loops, or avoid interfaces on hot paths.
See also all error codes and marmot explain.
M0110 possible nil dereference
A pointer is dereferenced, or a map written to, where it can be nil: it is nil on one path into the use (var p *T; if c { p = &T{} }; p.f), or it comes from a function that returns nil with a nil error (or with ok true), in this package or another.
cgo
Packages that import "C" build with marmot, and C calls are direct native calls.