BTW: Thanks for all this investigation and writeups, they are interesting, and I look forward to your test results.
Desipte my question, I think using a custom allocator is perfectly reasonable. go/issues/23199 is showing us that sync.Pool's interface isn't great for allocating byte-bufffers (it'd be better to explicitly ask for objects of a given size). In that sense, a custom allocator with an appropriate interface is more future-proof. > what I understand reading that issue is that sync.Pool is not the best > choice to store variable-length buffers and my first allocator I think the problem is that the total memory usage of the pool ends up O(size of large objects * total numer of objects kept). This is very wasteful if you need lots of small objects and only a few large ones. > implementation accepts buffers of any size, each received packet can > have different sizes (between 20 and 262144 bytes). So every 20 byte object will pin down ~100kiB of actual memory, which sounds pretty wasteful, but might be acceptable. > in general and currently, in my not yet public branch, I only allocate > packets of 2 different sizes and so sync.Pool could be appropriate, I'll You could have two separate pools, one for each size. This is basically a bucketed-allocator, but simpler because you already know the structure of your buckets. -- Adrian Ratnapala -- 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/CAN%2BHj7jeDGUj%3DT8-n7RMuv2i_soHMJ78M8bWOpkVq_-g3n7v5g%40mail.gmail.com.
