fmt: sloppy struct field arrangement could be re-done for efficiency/RAM reduction

[odeke-em]

Coming here from tip ecc3f51, with a tool we've developed at Orijtech, Inc, it reported

/Users/emmanuelodeke/go/src/go.googlesource.com/go/src/fmt/format.go:41:10: struct has size 112,
could be 104, rearrange to struct{buf *buffer; wid int; prec int; intbuf [68]byte; fmtFlags} for
optimal size

because

go/src/fmt/format.go

Lines 41 to 52 in ecc3f51

	type fmt struct {
	buf *buffer
	fmtFlags
	wid int // width
	prec int // precision
	// intbuf is large enough to store %b of an int64 with a sign and
	// avoids padding at the end of the struct on 32 bit architectures.
	intbuf [68]byte
	}

which when rearranged would become 7.14% more efficient as per https://play.golang.org/p/I8aIwwdbZYw.

Similar to #42412

[martisch]

It is not sloppy but engineered this way, but not documented explicitly.

Ram:
Going from 112 to 104 bytes does not save Ram because the next lower size class is 96 bytes.

Efficiency:
I tried around with this alot in https://go-review.googlesource.com/c/go/+/20984 and back then it always made format slower potentially due to alignment change on the buffer or being more cache friendly at the end. I was using https://github.com/dominikh/go-structlayout back then.

We should benchmark fmt on amd64 and 386 before making any change to that struct.

[odeke-em]

Thanks @martisch, and you are right about the RAM-no-savings: we added size class recognition and it no longer complains. Should we close this issue then?

[martisch]

Since there are no ram savings I would say lets close this for now. Im not sure its worth toying with that structure ordering for performance gains. They would need to be verified outside microbenchmarks to make sure anyway.