Il 11/03/20 22:55, Adrian Ratnapala ha scritto:
> >
> > Any particular reason you avoided something like sync.Pool ? It
could be useful in your case, allocation pattern depending.
> >
> Hi,
>
> I initially evaluated the sync.Pool then I read this article:
>
> https://dzone.com/articles/memory-pooling-in-go-where-why-and-how
>
> and this issue:
>
> https://github.com/golang/go/issues/23199
So If I understand go/issues/23199 correctly, the problem is that
large allocations from the past hang around in the pool (and
apparently this is made worse by small allocations somehow pinning them).
I can see how this can be a problem, but is it a problem *for you*?
You say that the allocations in question are for packets -- which I
would assume all count as small.
what I understand reading that issue is that sync.Pool is not the best
choice to store variable-length buffers and my first allocator
implementation accepts buffers of any size, each received packet can
have different sizes (between 20 and 262144 bytes).
As said before I'm reviewing the allocator and the allocation strategy
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
do some more tests and benchmarks before submitting the pull request for
the allocator,
thanks
Nicola
--
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/c24792b7-cf74-9bee-eabb-a3efef697089%40gmail.com.
