←back to thread

Go Optimization Guide

(goperf.dev)
480 points jedeusus | 2 comments | 31 Mar 25 20:29 UTC | HN request time: 0.001s | source
Show context
dennis-tra ◴[01 Apr 25 12:15 UTC] No.43545831[source]▶
Can someone explain to me why the compiler can’t do struct-field-alignment? This feels like something that can easily be automated.
replies(3): >>43545865 #>>43549815 #>>43554401 #
CamouflagedKiwi ◴[01 Apr 25 12:20 UTC] No.43545865[source]▶
Because the order of fields can be significant. It's very relevant for syscalls, and is observable via the reflect package; it'd be strange if the field order was arbitrarily changed (and might change further between releases).

I assume the thinking was that this is pretty easy to optimise if you care, and if it's on by default there'd then have to be some opt-out which there isn't a good mechanism for.

replies(2): >>43545977 #>>43549682 #
kbolino ◴[01 Apr 25 12:31 UTC] No.43545977[source]▶
In particular, struct field alignment matches C (even without cgo) and so any change to the default would break a lot of code.
replies(2): >>43549957 #>>43552073 #
9rx ◴[01 Apr 25 18:26 UTC] No.43549957[source]▶
> struct field alignment matches C (even without cgo)

The spec defines alignment for numeric types, but that's about it. There is nothing in the spec about struct layout. That is implementation dependent. If you are relying on a particular implementation, you are decidedly in unsafe territory.

> so any change to the default would break a lot of code.

The compiler can disable optimization on cgo calls automatically and most other places where it matters are via the standard library, so it might not be as much as you think. And if you still have a case where it matters, that is what this is for: https://pkg.go.dev/structs#HostLayout

replies(2): >>43550258 #>>43550697 #
arp242 ◴[01 Apr 25 19:52 UTC] No.43550697[source]▶
> There is nothing in the spec about struct layout

De-facto a lot of programs rely on it, so whatever the spec says is irrelevant.

Not just for cgo by the way, but also things like binary.Read()/Write().

replies(1): >>43550826 #
1. 9rx ◴[01 Apr 25 20:08 UTC] No.43550826[source]▶
> but also things like binary.Read()/Write().

binary.Read/Write already uses reflect as far as I can tell, so it wouldn't matter in that case. There is an optimization for numeric values in there, which may be what you are thinking of? But they are specified in the spec and that's not what we're talking about anyway (and if an optimization really had to go, for whatever reason, it wouldn't be the end of the world).

Did you mean something else?

replies(1): >>43585446 #
2. kbolino ◴[04 Apr 25 17:29 UTC] No.43585446[source]▶
I had to think about this one a bit.

Basically, binary.Read/binary.Write are capable of reading/writing struct values. The worry would be that, if the Go compiler reordered fields under the hood, the order may differ between writing the data and reading it back (especially across different versions of Go).

However, because these functions use reflection, they likely wouldn't be affected. While the in-memory layout of the struct fields might get reordered, presumably the reflection order would match the declaration order. Indeed, there is already an Offset field on the reflect.StructField type, and there is no statement anywhere I can find that such offsets must increase monotonically.

So, the fields would remain in declaration order when inspected with reflection, but their offsets could jump around within the struct, yet well behaved reflection-based code should be agnostic to this change.