Make singleton datatypes more efficient in Go

[tchajed]

Fixes #1214. I'm not very serious about this implementation, I just wanted to show what I managed to do with a little hacking.

Currently, a simple "record" inductive like datatype Astruct = A(x: uint64, y: bool) gets compiled to a Go struct with an interface that only ever has one implementing struct. This creates an unnecessary indirection. This PR replaces that interface with the single constructor's concrete struct type.

The change here is designed to minimize changes to the compiler and share with the case where the datatype has more than one constructor as much as possible. More aggressively for such records we could get rid of the interface type entirely, or also simplify the String() and Equals() implementations. I've benchmarked this change and it does seem to fix the performance problems I had with the normal Dafny output. It's not huge but I do observe a difference, maybe 5% faster for a regular benchmark that shouldn't be bottlenecked on creating structs; an artificial benchmark that creates a lot of structs goes from 83ns to do a functional update to a struct down to 3ns with this PR.

[keyboardDrummer]

I do observe a difference, maybe 5% faster for a regular benchmark that shouldn't be bottlenecked on creating structs; an artificial benchmark that creates a lot of structs goes from 83ns to do a functional update to a struct down to 3ns with this PR.

Having performance tests in Dafny for the generated code would be super useful. I imagine the performance threshold would be configured per output language. Given your interest in GoLang's performance, is adding such a performance test something you're interested in? It could start out small.

[RustanLeino]

I like this change.

A similar change would be nice for the other compiler targets as well, but that doesn't need to hold up this PR. For the record (no pun intended), note that the analogous optimization for C# can be done only if all type parameters of the datatype are non-variant, because type variance in C# can only be indicated via an interface. (Oh, but that reminds me--that's not implemented for C# and Java at the moment, anyway.)