We changed the way we track Go threads in syscalls/cgo calls, which allowed us to remove one atomic store and one atomic compare-and-swap from the cgo call path. https://go.dev/cl/646198 and https://go.dev/cl/708596 are the relevant changes.

(It's basically an easter egg, but if you look at the source of the release notes, you will see that most entries in the release notes have an HTML comment referencing the Go CL or issue that the entry refers to.)

Now if only the Go gods would grant us in line ternaries to avoid all of the overly verbose nil checks, I'd be more likely to use pointer values in structs. Right now they're big foot guns that the compiler won't catch (and AFAIK no linter will check if you did a nil check before accessing).

I have a tech debt TODO on my backlog to rationalize null usage (waiting on encoding/jsonv2) where I'll go through structs and better determine which properties should be null (or even empty) both from a JSON and DB perspective, especially with custom types in the mix. Hopefully reducing the amount of possible values the TS frontend needs to handle...

see: https://go-review.googlesource.com/c/go/+/707755 and https://go-review.googlesource.com/c/go/+/664299

Looks for slices with lengths <= 32.