On Wed, May 3, 2017 at 4:24 PM Piotr Narewski <piotr...@gmail.com> wrote:
> I've just tried it and unfortunately it doesn't seem to be better than
the traditional approach.
>
> With the pool in place, it still user too much memory (unlike my solution
with using a heap via glibc).
Sorry to hear that. There are few things worth checking:
- slice.Put must be called once the slice will be no more used.
- The program may not keep any references to the slice passed to slice.Put.
- If you use append on the slice returned from slice.Get() you will
effectively stop using the pool as append can allocate a new backing array
but not by calling slice.Get/CGet. IOW, in such cases it's also necessary
to write one's own append ;-)
The best way to figure out where the memory consumption is happening when
using slice.Pool is to profile it, example:
$ go test -run @ -bench . -memprofile mem.out -memprofilerate 1
$ go tool pprof -lines -web -alloc_space *.test mem.out
--
-j
--
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.
For more options, visit https://groups.google.com/d/optout.
