We've tried not to specialize the compiler against "regular" packages in the standard library.

Taking regular packages from std and moving them to github or a project's vendor directory should not affect their performance.

Sometimes we specialize for special packages (reflect, runtime, maybe even time), but not "encoding/binary".

I understand the reasoning, but the result of this is, as I understand it, that the binary package is (regarded as) slow and ends up unused, with hand-crafted (sometimes unsafe) code used in its place.

To be clear, I'm only opposed to special-casing on the (package name, function name) pair alone. It would be acceptable to make the compiler recognize the structure of the function and special-cases on that instead.

I'm with @bradfitz.

What about adding a (cached) reflect.HasPadding to detect structs that contain no pointers and have no padding? That should allow to implement the optimization in pure Go in the package, without any special casing in the compiler.

@rasky, this bug isn't about structs. @dr2chase mentioned compile-time constants (and structs can't be constant). Even with variables, it'd be nice to eliminate the call overhead entirely ("intrinsify").

Uh? He wrote:

... and type of data interface{} are compile-time constants

Anyway, I do wonder how a compiler can reliably match a function as complex as encoding/binary and intrinsify it. In my experience, encoding/binary is very slow when it has to go through struct fields with reflection, and my suggestion would allow to skip that big overhead almost altogether (assuming reflect.HasPadding is cached and/or computed at compile-time). Call overhead could then be removed with inlining.

Another possibility might be to create a "BinaryReader" and "BinaryWriter" that would be created for objects of a specific type and data with a particular endianness, and used repeatedly afterwards, in the same way that regular expressions can be compiled into matchers.

And the obviously easy special case is an obviously easy special case.