Thanks. I've checked it and I think there is something wrong with this lib.
If I do: dat := make([]byte, 515) slice.Bytes.Put(&dat) println(dat) And then: p := slice.Bytes.Get(515).(*[]byte) println(*p) It returns me a different slice. To get the same slice, I need to go down from 515 to 512 bytes: p := slice.Bytes.Get(512).(*[]byte) println(*p) This is pretty much similar for any other length value: put 111 needs get 64, put 10000 needs 8192, etc. That's where I think it's eating up the mem. It just won't reuse a buffer of the same size. On Wednesday, May 3, 2017 at 4:42:28 PM UTC+2, Jan Mercl wrote: > > On Wed, May 3, 2017 at 4:24 PM Piotr Narewski <piot...@gmail.com > <javascript:>> 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.
