GENERATE IMPLEMENTATIONS FOR GENERIC TYPES

[ArnoldoR]

https://flaviocopes.com/golang-generic-generate/

it is an attractive idea

[emirpasic]

@ArnoldoR is this another code-generation tool? there have been other similar tools and i chose not to use it from the start feeling (subjectively) uneasy about this approach despite being aware that this would optimize performance and remove the need for type assertions. in other words, i am not keen on making this switch for the whole library, but would simply extend this library to have static typed generated files for all the structures. given the number of combinations of types, this would yield many many files, i.e. consider only how many types there are in golang and square that number to get combinations for key-value structures.

[bminer]

Generics may provide marginally better performance and use less RAM at runtime, but the generated binaries could get a little bloated. This is a bit of a holy war in the Golang community, but TBH the performance of interface{} with type assertions / unboxing is really quite good. Unfortunately, from a RAM usage perspective, an interface{} uses 4x the RAM of uint32 and 16x the RAM of byte (assuming 64-bit machine).

See for yourself:

var i interface{}
fmt.Println(unsafe.Sizeof(i))

Then again, we have languages like Java which "support generics", but they are still doing boxing / unboxing behind the scenes with overhead similar (or maybe worse?) to Golang's interface{}.

If performance is a key issue, it looks like code bloat is the only option.

[emirpasic]

@bminer I concur, the performance hit is maybe not too bad nowadays. There have been a few complaints a few years ago w.r.t. type assertions, but these might have been optimized in newer versions of Golang (actually not 100% sure, would need to investigate, for now just wishful thinking). In a more complex system, based on my experience, these type assertions within this library are least likely to be the cause for the slowdown.

However, the memory might be a bit of an issue, in that case I'd suggest a custom implementation for the given problem with static types. Again, there is so much unused RAM on computers today or it's used on other bloatware, so even that might not be too much of an issue in a larger system/environment.

What did you mean by 4x the RAM?

https://play.golang.org/p/l6HKSm_K9tS

[bminer]

I meant 4x the RAM on a 64-bit machine. The Go playground is a 32-bit machine. :)

Also, I was comparing interface{} to uint32 not to int.
int vs. interface{} is always a factor of 2.

To add to the conversation, often the overhead starts to disappear when we work with more complex data structures (i.e. structs, etc.). If we really need performance for a list of ints, using Golang's built-in slices are the way to go.

[emirpasic]

writing from phone, what would be the output of that on a 64-bit?

[bminer]

interface{} on 64-bit is 16 bytes (two 64-bit words).
int on 64-bit is 8 bytes (one 64-bit word).
int32 is always 4 bytes. You can fit 2 of them in a 64-bit word.

[emirpasic]

thanks @bminer , the interface part i wasn't sure of, otherwise makes sense.

things do get a bit more troubling with 8-bit types, e.g. bool, int8, etc.

in those cases interface{} will use 16 times more memory.