[slimsag]

It seems a bit contradictory to write a manual memory management library in Go and _then use type reflection as a shoehorned version of generics_.

It must be that the author only cares about GC pauses, i.e. 'nondeterministic' pauses -- not really perf itself?

[teh_cmc]

Yes, as I said in this comment [1]; my real issue here is lengthy GC pauses, which cause peaks in response times.

Regarding overall performances, I'm not really convinced that the reflect calls affect them that much (there's 2 reflect calls per Read() or Write() call), but I honestly just don't know, I'd have to bench to be sure. Although, if it turns out to actually be an issue, you can still use Pointer() to keep references to your unmanaged heap and you'll be able to work with your data without GC nor reflection overhead.

[1] https://news.ycombinator.com/item?id=10650885

[pcwalton]

Also, don't reflection and/or interface casts for anything larger than a pointer allocate on the GC heap in Go? That is, isn't it using GC to implement no-GC?