4 ms·
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 t
by slimsag 11y ago
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?
- pcwalton 11y agoAlso, 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?
- teh_cmc 11y agoYes, 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 https://news.ycombinator.com/item?id=10650885