Access to uint64 pair?

[brycekahle]

We serialize a lot of IP addresses, and rather than converting the internal uint64 pair to byte arrays and then back to uint64s, it would be great if we could get access to the uint64 pair values directly to use them for serialization. Also, the ability to construct a netaddr.IP from a uint64 pair would be useful for de-serialization.

[danderson]

I'm -1 on this, because not exposing internal implementation details has allowed us to change the internal representation 3 times so far, with huge benefits each time.

What kind of serialization are you doing? I'm curious why a pair of uint64s is significantly better than being able to get a [16]byte.

[bradfitz]

Also: numbers?

[brycekahle]

I'm -1 on this, because not exposing internal implementation details

Fair enough.

What kind of serialization are you doing?

Protobuf.

why a pair of uint64s is significantly better than being able to get a [16]byte

Because we don't want to spend the cost of converting the uint64 pair to [16]byte on every IP address, if we don't have to.

[dsnet]

This seems like a compiler optimization issue:

• It's unfortunate that As16 is not inlineable. See cmd/compile: make encoding/binary.LittleEndian.* have negligible inlining cost on amd64 golang/go#42958.
• If it were inlineable, the compiler should realize that storing a word into an intermediate [N]byte and loading it back out is a pointless operation and elide that logic. I don't know if there is an issue for that or whether the compiler already does this.

[josharian]

It's unfortunate that As16 is not inlineable.

I'll send a PR for golang/go#42958. I don't know that it'll get accepted, though.

the compiler should realize that...

If it doesn't do this already (it might), then the relevant issue is probably golang/go#24416.