net: sloppy struct field arrangement could be re-arranged for more compact structs

[odeke-em]

Coming here from tip ecc3f51, with one of the static analysis tools, we have developed at Orijtech, Inc., we've found 2
fields in the net package that could be re-arranged for optimal sizes, hence the usage of "sloppy struct field arrangement".

And here they are

net/dnsconfig_unix.go:23:16: struct has size 152 (size class 160), could be 144 (size class 144), rearrange to 
struct{mtime time.Time; search []string; servers []string; lookup []string; err error; timeout time.Duration;
attempts int; ndots int; soffset uint32; unknownOpt bool; rotate bool; singleRequest bool; useTCP bool}
for optimal size (10.00% savings)
net/dnsclient_unix_test.go:50:35: struct has size 296 (size class 320), could be 288 (size class 288),
rearrange to struct{server string; timeout int; question dnsmessage.Question; rcode dnsmessage.RCode}
for optimal size (10.00% savings)

[davecheney]

I don’t think there is a lot of value of analysing _test.go files.

[cuonglm]

I don’t think there is a lot of value of analysing _test.go files.

Sure, It's just an analysis pass, so I think it currently does the same as what analysis passes do. Is there an option for analysis pass skip test files 🤔

[odeke-em]

I don’t think there is a lot of value of analysing _test.go files.

@davecheney does have a point, I thought about that too, but we were trying to be as thorough as possible!
@cuonglm let's skip _test.go files, and perhaps make them an explicit opt-in instead.

[toothrot]

/cc @bradfitz @ianlancetaylor

[rsc]

The struct identified here - type dnsConfig - is something that there's typically only one of in an entire program. The savings of 16 bytes in an entire program, at the cost of making the struct field list less natural to read, is not worth it.

Echoing what I wrote on #42412, you can improve the targeting of your suggestions by combining your tool with memory profiles. It's important not to make changes to code that doesn't actually have any benefit to being changed. That can only introduce bugs - all risk, no reward.

[rsc]

Given that dnsConfig shouldn't be changed and the other is in a test and shouldn't be changed, closing this.