Most active commenters
  • 9rx(4)
  • kbolino(3)

←back to thread

Go Optimization Guide

(goperf.dev)
480 points jedeusus | 13 comments | 31 Mar 25 20:29 UTC | HN request time: 0.001s | source | bottom
1. 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 #
2. 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 #
3. 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 #
4. 9rx ◴[01 Apr 25 17:56 UTC] No.43549682[source]▶
> and if it's on by default there'd then have to be some opt-out which there isn't a good mechanism for.

Good is subjective, but the mechanism is something already implemented: https://pkg.go.dev/structs#HostLayout

replies(1): >>43556694 #
5. 9rx ◴[01 Apr 25 18:12 UTC] No.43549815[source]▶
Like the answer to all "Why doesn't Go have X?" questions: Lack of manpower. There has been some work done to support it, but is far from complete. Open source doesn't mean open willingness to contribute, unfortunately. Especially when you're not the cool kid on the block.
6. 9rx ◴[01 Apr 25 18:26 UTC] No.43549957{3}[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 #
7. kbolino ◴[01 Apr 25 19:00 UTC] No.43550258{4}[source]▶
That's good to know. I'm not making use of this assumption, but the purego package (came from ebitengine) does. It looks like they're aware of HostLayout [1] but I'm not sure how many other people have gotten the memo (HostLayout didn't exist before Go 1.23).

[1]: https://github.com/ebitengine/purego/issues/259

8. arp242 ◴[01 Apr 25 19:52 UTC] No.43550697{4}[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 #
9. 9rx ◴[01 Apr 25 20:08 UTC] No.43550826{5}[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 #
10. int_19h ◴[01 Apr 25 22:47 UTC] No.43552073{3}[source]▶
This is very unfortunate, since most structs are never going to be passed to C, yet end up paying the tax anyway. They really should have made it opt-in.
11. masklinn ◴[02 Apr 25 07:23 UTC] No.43554401[source]▶
It can. Rust does.

That requires a way to opt out tho, because there are situations where you need a specific field ordering, so now the langage needs to provide way to tune struct compilation behaviour.

12. CamouflagedKiwi ◴[02 Apr 25 13:51 UTC] No.43556694{3}[source]▶
Oh interesting, I've not encountered that before - I suppose because it is currently the default behaviour.

What I was hoping not to find (and fortunately didn't!) was one of Go's magical syntactic comments.

13. kbolino ◴[04 Apr 25 17:29 UTC] No.43585446{6}[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.