On Monday, June 22, 2020 at 5:42:12 PM UTC-4, rog wrote: > > > Thanks for pointing this out. I'm cool with this approach. I'll update my >>> library to utilize it (and consider also adopting the list.List, though I >>> do like my freedom to pool list nodes). >>> >> > Personally, I'd start by re-using list.List, and only use pools if there > really is a significant performance benefit to be gained there. > If you just need zero-valued elements, I could imagine that sync.Pool > might end up slower than just using the GC. >
Fair. > Hopefully with aggressive inlining of the specialized type the compiler >>> will be able to make the optimizations that it would be able to make if the >>> slicing were performed directly on an array. >>> >> > What optimisations are you thinking of here? Are you concerned that slice > operations are too slow? > * Bound check elimination * Avoiding an indirection through the pointer in the slice header would be nice * Compile-time evaluation of len and cap IIUC all of these would happen if we were operating on a raw array type rather than a slice. > cheers, > rog. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/6a6bd9d6-deec-42f2-a9d8-7a1413221f4do%40googlegroups.com.
