FAQ
Yes, Go is the GC language, however, should we let the Go itself to take
care of the memory management?

This module seems to be useful, but not sure the pro and con to implement
it.

https://github.com/couchbase/go-slab

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Tamás Gulácsi at Feb 28, 2016 at 11:51 am
    Hard to use, ideal for shooting yourself on the foot.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Egon at Feb 28, 2016 at 1:43 pm

    On Sunday, 28 February 2016 12:56:17 UTC+2, Andy wrote:
    Yes, Go is the GC language, however, should we let the Go itself to take
    care of the memory management?
    It depends what you are doing, but if you need to ask that question, then
    you should Go-s GC.

    However, there are cases, usually regarding to high-performance, where you
    want to manage your own memory. *E.g. maximum memory limits, memory mapped
    program state, command buffers, lots of small items with pointers.* When
    you are finally put into such situation, you will (need to) know how
    exactly memory is used, iterated and how things created and released -->
    only then you can make a good decision which memory allocation to use.

    + Egon

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ojucie at Feb 28, 2016 at 2:07 pm
    Disclaimer: I am a shameless fanboy of Go garbage collector. Sorry for that.

    Up to version 1.4 the GC was good enough for all but the more extreme
    cases, when it could stop the world for some seconds.
    In version 1.5 it got pretty good even for those extreme cases. Not humanly
    perceptible pauses anymore.
    In version 1.6 it got even better, believe it or not, to the point you can
    use Go for real time applications like stock trading, for instance.

    That said, the alternative approach you suggests, Andy, can be useful in
    some circumstances, as Egon so aptly explained.
    On Sunday, February 28, 2016 at 7:56:17 AM UTC-3, Andy wrote:

    Yes, Go is the GC language, however, should we let the Go itself to take
    care of the memory management?

    This module seems to be useful, but not sure the pro and con to implement
    it.

    https://github.com/couchbase/go-slab
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jérôme LAFORGE at Feb 28, 2016 at 6:43 pm
    Just for your info :
    http://play.golang.org/p/UKKOQuWZFj

    Testing started at 19:42 ...
    testing: warning: no tests to run
    PASS
    BenchmarkSlab-4 20000000 110 ns/op 0 B/op
            0 allocs/op
    BenchmarkClassicMake-4 1000000 1126 ns/op 4096 B/op
            1 allocs/op
    BenchmarkSyncPool-4 20000000 95.1 ns/op 32
    B/op 1 allocs/op
    ok cmd/slab/bench 5.471s

    Le dimanche 28 février 2016 15:07:35 UTC+1, oju...@gmail.com a écrit :
    Disclaimer: I am a shameless fanboy of Go garbage collector. Sorry for
    that.

    Up to version 1.4 the GC was good enough for all but the more extreme
    cases, when it could stop the world for some seconds.
    In version 1.5 it got pretty good even for those extreme cases. Not
    humanly perceptible pauses anymore.
    In version 1.6 it got even better, believe it or not, to the point you can
    use Go for real time applications like stock trading, for instance.

    That said, the alternative approach you suggests, Andy, can be useful in
    some circumstances, as Egon so aptly explained.
    On Sunday, February 28, 2016 at 7:56:17 AM UTC-3, Andy wrote:

    Yes, Go is the GC language, however, should we let the Go itself to take
    care of the memory management?

    This module seems to be useful, but not sure the pro and con to implement
    it.

    https://github.com/couchbase/go-slab
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ojucie at Feb 28, 2016 at 11:35 pm
    Nice comparison, Jérôme. Thanks for exposing yet another alterative,
    sync.Pool . Very enlightening.
    On Sunday, February 28, 2016 at 3:43:29 PM UTC-3, Jérôme LAFORGE wrote:

    Just for your info :
    http://play.golang.org/p/UKKOQuWZFj

    Testing started at 19:42 ...
    testing: warning: no tests to run
    PASS
    BenchmarkSlab-4 20000000 110 ns/op 0 B/op
    0 allocs/op
    BenchmarkClassicMake-4 1000000 1126 ns/op 4096 B/op
    1 allocs/op
    BenchmarkSyncPool-4 20000000 95.1 ns/op 32
    B/op 1 allocs/op
    ok cmd/slab/bench 5.471s

    Le dimanche 28 février 2016 15:07:35 UTC+1, oju...@gmail.com a écrit :
    Disclaimer: I am a shameless fanboy of Go garbage collector. Sorry for
    that.

    Up to version 1.4 the GC was good enough for all but the more extreme
    cases, when it could stop the world for some seconds.
    In version 1.5 it got pretty good even for those extreme cases. Not
    humanly perceptible pauses anymore.
    In version 1.6 it got even better, believe it or not, to the point you
    can use Go for real time applications like stock trading, for instance.

    That said, the alternative approach you suggests, Andy, can be useful in
    some circumstances, as Egon so aptly explained.
    On Sunday, February 28, 2016 at 7:56:17 AM UTC-3, Andy wrote:

    Yes, Go is the GC language, however, should we let the Go itself to take
    care of the memory management?

    This module seems to be useful, but not sure the pro and con to
    implement it.

    https://github.com/couchbase/go-slab
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Egon at Feb 29, 2016 at 8:04 am

    On Sunday, 28 February 2016 20:43:29 UTC+2, Jérôme LAFORGE wrote:
    Just for your info :
    http://play.golang.org/p/UKKOQuWZFj

    Testing started at 19:42 ...
    testing: warning: no tests to run
    PASS
    BenchmarkSlab-4 20000000 110 ns/op 0 B/op
    0 allocs/op
    BenchmarkClassicMake-4 1000000 1126 ns/op 4096 B/op
    1 allocs/op
    BenchmarkSyncPool-4 20000000 95.1 ns/op 32
    B/op 1 allocs/op
    ok cmd/slab/bench 5.471s
    http://play.golang.org/p/pBIEotFUHO

    BenchmarkSlab-8 10000000 133 ns/op 0 B/op 0 allocs/op
    BenchmarkClassicMake-8 1000000 2692 ns/op 4096 B/op 1 allocs/op
    BenchmarkSyncPool-8 10000000 127 ns/op 32 B/op 1 allocs/op
    BenchmarkArena-8 20000000 60.3 ns/op 53 B/op 0 allocs/op

    And, I didn't bother optimizing the BenchmarkArena. *Misusing will cause a
    crash in the best case.*

    + Egon

    Le dimanche 28 février 2016 15:07:35 UTC+1, oju...@gmail.com a écrit :
    Disclaimer: I am a shameless fanboy of Go garbage collector. Sorry for
    that.

    Up to version 1.4 the GC was good enough for all but the more extreme
    cases, when it could stop the world for some seconds.
    In version 1.5 it got pretty good even for those extreme cases. Not
    humanly perceptible pauses anymore.
    In version 1.6 it got even better, believe it or not, to the point you
    can use Go for real time applications like stock trading, for instance.

    That said, the alternative approach you suggests, Andy, can be useful in
    some circumstances, as Egon so aptly explained.
    On Sunday, February 28, 2016 at 7:56:17 AM UTC-3, Andy wrote:

    Yes, Go is the GC language, however, should we let the Go itself to take
    care of the memory management?

    This module seems to be useful, but not sure the pro and con to
    implement it.

    https://github.com/couchbase/go-slab
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Davis at Feb 29, 2016 at 10:42 am
    Seems to me that the sync.Pool benchmark is mainly just benchmarking
    allocating and putting the result into a pool since it's in a tight
    single threaded loop.

    For my own amusement I wrote parallel benchmarks for the first three. I
    didn't bother for the Arena since it didn't have any kind of locking to
    make it useful in a concurrent environment.

    http://play.golang.org/p/2hnN1Z175_

    10:36 $ go test -benchmem -bench=.* testing: warning: no tests to run
    PASS BenchmarkSlab-8              20000000           113 ns/op
    0 B/op           0 allocs/op BenchmarkSlabPar-8            5000000
    248 ns/op           0 B/op           0 allocs/op BenchmarkClassicMake-8
    1000000          1467 ns/op        4096 B/op           1 allocs/op BenchmarkClassicMakePar-
    8     2000000           877 ns/op        4096 B/op           1 allocs/op
    BenchmarkSyncPool-8          10000000           241 ns/op          32
    B/op           1 allocs/op BenchmarkSyncPoolPar-8       50000000
    33.5 ns/op          32 B/op           1 allocs/op



    On Mon, Feb 29, 2016, at 08:04 AM, Egon wrote:

    On Sunday, 28 February 2016 20:43:29 UTC+2, Jérôme LAFORGE wrote:
    Just for your info : http://play.golang.org/p/UKKOQuWZFj

    Testing started at 19:42 ... testing: warning: no tests to run PASS
    BenchmarkSlab-4           20000000           110 ns/op           0
    B/op           0 allocs/op BenchmarkClassicMake-4     1000000
    1126 ns/op        4096 B/op           1 allocs/op BenchmarkSyncPool-4
    20000000            95.1 ns/op          32 B/op           1 allocs/op
    ok      cmd/slab/bench    5.471s
    http://play.golang.org/p/pBIEotFUHO

    BenchmarkSlab-8         10000000  133 ns/op    0 B/op 0 allocs/op BenchmarkClassicMake-
    8   1000000 2692 ns/op 4096 B/op 1 allocs/op BenchmarkSyncPool-8
    10000000  127 ns/op   32 B/op 1 allocs/op BenchmarkArena-8
    20000000 60.3 ns/op   53 B/op 0 allocs/op

    And, I didn't bother optimizing the BenchmarkArena. *Misusing will
    cause a crash in the best case.*

    + Egon
    Le dimanche 28 février 2016 15:07:35 UTC+1, oju...@gmail.com a
    écrit :
    Disclaimer: I am a shameless fanboy of Go garbage collector. Sorry
    for that.

    Up to version 1.4 the GC was good enough for all but the more
    extreme cases, when it could stop the world for some seconds. In
    version 1.5 it got pretty good even for those extreme cases. Not
    humanly perceptible pauses anymore. In version 1.6 it got even
    better, believe it or not, to the point you can use Go for real time
    applications like stock trading, for instance.

    That said, the alternative approach you suggests, Andy, can be
    useful in some circumstances, as Egon so aptly explained. On Sunday,
    February 28, 2016 at 7:56:17 AM UTC-3, Andy wrote:
    Yes, Go is the GC language, however, should we let the Go itself to
    take care of the memory management?

    This module seems to be useful, but not sure the pro and con to
    implement it.

    https://github.com/couchbase/go-slab
    --
    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+unsubscribe@googlegroups.com.
    >
    For more options, visit https://groups.google.com/d/optout.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Egon at Feb 29, 2016 at 11:02 am

    On Monday, 29 February 2016 12:43:04 UTC+2, Ian Davis wrote:
    Seems to me that the sync.Pool benchmark is mainly just benchmarking
    allocating and putting the result into a pool since it's in a tight single
    threaded loop.

    For my own amusement I wrote parallel benchmarks for the first three. I
    didn't bother for the Arena since it didn't have any kind of locking to
    make it useful in a concurrent environment.
    Here you go, one for concurrent use http://play.golang.org/p/qRGa6nde51

    BenchmarkSlab-8 10000000 138 ns/op 0 B/op 0 allocs/op
    BenchmarkClassicMake-8 500000 2598 ns/op 4096 B/op 1 allocs/op
    BenchmarkSyncPool-8 10000000 136 ns/op 32 B/op 1 allocs/op
    BenchmarkArena-8 100000000 15.9 ns/op 10 B/op 0 allocs/op

    BenchmarkSlabPar-8 10000000 198 ns/op 0 B/op 0 allocs/op
    BenchmarkClassicMakePar-8 500000 3046 ns/op 4096 B/op 1 allocs/op
    BenchmarkSyncPoolPar-8 30000000 57.0 ns/op 32 B/op 1 allocs/op
    BenchmarkArenaPar-8 50000000 24.1 ns/op 21 B/op 0 allocs/op

    *Obviously, the arena version has totally overflowed... so you would expect
    fun things if you actually tried to write into it. :)*
    *And yes I know, It's an unfair comparison, because it assumes that you
    know in advance how much memory you will use.*
    *And, it very well demonstrates the reason why you would want to use
    something like that, and also the reasons why you*
    *wouldn't use one usually :D.*

    + Egon

    http://play.golang.org/p/2hnN1Z175_

    10:36 $ go test -benchmem -bench=.*
    testing: warning: no tests to run
    PASS
    BenchmarkSlab-8 20000000 113 ns/op 0
    B/op 0 allocs/op
    BenchmarkSlabPar-8 5000000 248 ns/op 0
    B/op 0 allocs/op
    BenchmarkClassicMake-8 1000000 1467 ns/op 4096
    B/op 1 allocs/op
    BenchmarkClassicMakePar-8 2000000 877 ns/op 4096
    B/op 1 allocs/op
    BenchmarkSyncPool-8 10000000 241 ns/op 32
    B/op 1 allocs/op
    BenchmarkSyncPoolPar-8 50000000 33.5 ns/op 32
    B/op 1 allocs/op




    On Mon, Feb 29, 2016, at 08:04 AM, Egon wrote:



    On Sunday, 28 February 2016 20:43:29 UTC+2, Jérôme LAFORGE wrote:

    Just for your info :
    http://play.golang.org/p/UKKOQuWZFj

    Testing started at 19:42 ...
    testing: warning: no tests to run
    PASS
    BenchmarkSlab-4 20000000 110 ns/op 0 B/op
    0 allocs/op
    BenchmarkClassicMake-4 1000000 1126 ns/op 4096 B/op
    1 allocs/op
    BenchmarkSyncPool-4 20000000 95.1 ns/op 32
    B/op 1 allocs/op
    ok cmd/slab/bench 5.471s


    http://play.golang.org/p/pBIEotFUHO

    BenchmarkSlab-8 10000000 133 ns/op 0 B/op 0 allocs/op
    BenchmarkClassicMake-8 1000000 2692 ns/op 4096 B/op 1 allocs/op
    BenchmarkSyncPool-8 10000000 127 ns/op 32 B/op 1 allocs/op
    BenchmarkArena-8 20000000 60.3 ns/op 53 B/op 0 allocs/op

    And, I didn't bother optimizing the BenchmarkArena. *Misusing will cause
    a crash in the best case.*

    + Egon


    Le dimanche 28 février 2016 15:07:35 UTC+1, oju...@gmail.com a écrit :

    Disclaimer: I am a shameless fanboy of Go garbage collector. Sorry for
    that.

    Up to version 1.4 the GC was good enough for all but the more extreme
    cases, when it could stop the world for some seconds.
    In version 1.5 it got pretty good even for those extreme cases. Not
    humanly perceptible pauses anymore.
    In version 1.6 it got even better, believe it or not, to the point you can
    use Go for real time applications like stock trading, for instance.

    That said, the alternative approach you suggests, Andy, can be useful in
    some circumstances, as Egon so aptly explained.
    On Sunday, February 28, 2016 at 7:56:17 AM UTC-3, Andy wrote:

    Yes, Go is the GC language, however, should we let the Go itself to take
    care of the memory management?

    This module seems to be useful, but not sure the pro and con to implement
    it.

    https://github.com/couchbase/go-slab


    --
    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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Davis at Feb 29, 2016 at 11:05 am

    On Mon, Feb 29, 2016, at 11:02 AM, Egon wrote:
    On Monday, 29 February 2016 12:43:04 UTC+2, Ian Davis wrote:
    Seems to me that the sync.Pool benchmark is mainly just benchmarking
    allocating and putting the result into a pool since it's in a tight
    single threaded loop.

    For my own amusement I wrote parallel benchmarks for the first three.
    I didn't bother for the Arena since it didn't have any kind of
    locking to make it useful in a concurrent environment.
    Here you go, one for concurrent use
    http://play.golang.org/p/qRGa6nde51

    BenchmarkSlab-8           10000000     138 ns/op        0 B/op   0
    allocs/op BenchmarkClassicMake-8      500000    2598 ns/op     4096
    B/op   1 allocs/op BenchmarkSyncPool-8       10000000     136 ns/op
    32 B/op   1 allocs/op BenchmarkArena-8          100000000     15.9
    ns/op     10 B/op   0 allocs/op

    BenchmarkSlabPar-8        10000000     198 ns/op        0 B/op   0
    allocs/op BenchmarkClassicMakePar-8   500000    3046 ns/op     4096
    B/op   1 allocs/op BenchmarkSyncPoolPar-8    30000000      57.0 ns/op
    32 B/op   1 allocs/op BenchmarkArenaPar-8       50000000      24.1
    ns/op     21 B/op   0 allocs/op

    **Obviously*, the arena version has totally overflowed... so you would
    expect fun things if you actually tried to write into it. :)* *And yes
    I know, It's an unfair comparison, because it assumes that you know in
    advance how much memory you will use.* *And, it very well demonstrates
    the reason why you would want to use something like that, and also the
    reasons why you* *wouldn't use one usually :D.*
    Why does the parallel version allocate a different amount of memory per
    op compared with the single threaded one?

    Ian


    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Egon at Feb 29, 2016 at 11:50 am

    On Monday, 29 February 2016 13:05:35 UTC+2, Ian Davis wrote:
    On Mon, Feb 29, 2016, at 11:02 AM, Egon wrote:

    On Monday, 29 February 2016 12:43:04 UTC+2, Ian Davis wrote:

    Seems to me that the sync.Pool benchmark is mainly just benchmarking
    allocating and putting the result into a pool since it's in a tight single
    threaded loop.

    For my own amusement I wrote parallel benchmarks for the first three. I
    didn't bother for the Arena since it didn't have any kind of locking to
    make it useful in a concurrent environment.


    Here you go, one for concurrent use http://play.golang.org/p/qRGa6nde51

    BenchmarkSlab-8 10000000 138 ns/op 0 B/op 0
    allocs/op
    BenchmarkClassicMake-8 500000 2598 ns/op 4096 B/op 1
    allocs/op
    BenchmarkSyncPool-8 10000000 136 ns/op 32 B/op 1
    allocs/op
    BenchmarkArena-8 100000000 15.9 ns/op 10 B/op 0
    allocs/op

    BenchmarkSlabPar-8 10000000 198 ns/op 0 B/op 0
    allocs/op
    BenchmarkClassicMakePar-8 500000 3046 ns/op 4096 B/op 1
    allocs/op
    BenchmarkSyncPoolPar-8 30000000 57.0 ns/op 32 B/op 1
    allocs/op
    BenchmarkArenaPar-8 50000000 24.1 ns/op 21 B/op 0
    allocs/op

    *Obviously, the arena version has totally overflowed... so you would
    expect fun things if you actually tried to write into it. :)*
    *And yes I know, It's an unfair comparison, because it assumes that you
    know in advance how much memory you will use.*
    *And, it very well demonstrates the reason why you would want to use
    something like that, and also the reasons why you*
    *wouldn't use one usually :D.*


    Why does the parallel version allocate a different amount of memory per op
    compared with the single threaded one?
    The arena size is fixed, but the number of iterations is different and this
    causes B/op be different.

    Since we are iterating different amounts, all other numbers aren't perfect
    either.
    Ideally those tests should look like:

    for i := 0; i < t.N; i++ {
    arena.Reset()
    for i := 0; i < 1024; i++ {
    arena.Alloc(alloc)
    }
    }

    But, for rough estimates the current version is fine.

    + Egon

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jesper Louis Andersen at Feb 29, 2016 at 12:11 pm

    On Sun, Feb 28, 2016 at 11:56 AM, Andy wrote:

    Yes, Go is the GC language, however, should we let the Go itself to take
    care of the memory management?

    I would let the GC handle memory management until you can demonstrate your
    problem would benefit from using another method. At that point, you may
    find that a rewrite using sync.Pool is fast enough. If that fails, and you
    can demonstrate you need the extra performance, drop to handling your own
    Arena.

    The price of doing such work yourself is much lower productivity as a
    programmer.

    In earlier Go versions, 1.4 and before, isolating part of the memory space
    in order to improve pause time latency was sometimes needed. In 1.5 and 1.6
    you shouldn't do that to get lower pause time latencies as the GC only
    blocks the world when it gets close to mark termination, and doesn't keep
    the block for long, even for massive heaps of several hundred gigabytes in
    size.

    The sacrifice for the low pause time latencies are slower throughput of the
    program in general. So it may still be that your problem needs to isolate
    part of the heap so it doesn't allocate and force the GC work upon you. But
    this can often be alleviated by adherence to the principle of not
    allocating data in the first place and using sync.Pool in the critical
    bottleneck parts of the program.

    In short: study the GC of the programming language you use. Write the
    program so it is not in opposition to the GC, and your program will often
    be fast. You usually have to do some extraordinary work in order to beat
    the GC algorithm and a simple naive approach is often slower than just
    using the GC like it was intended to be used.

    Also beware of just measuring the critical loop and heed Amdahl's law. Real
    programs allocate in all kinds of places so it may be more beneficial to
    the overall performance to fix allocation rates in other parts of the
    system first. My experience is that larger programs are more susceptible to
    bad performance due to unforeseen outliers in the 99th percentile of
    operation than in their main loop. And improving the 99th percentile can
    often improve the overall system behavior, even if it comes at a cost to
    the median.




    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Damian Gryski at Feb 29, 2016 at 12:33 pm

    On Sunday, February 28, 2016 at 11:56:17 AM UTC+1, Andy wrote:
    Yes, Go is the GC language, however, should we let the Go itself to take
    care of the memory management?

    This module seems to be useful, but not sure the pro and con to implement
    it.

    https://github.com/couchbase/go-slab
    Several years ago (go 1.2 -> go 1.3) I used this slab allocator in a
    proof-of-concept high-throughput udp->tcp relay. Using the slab allocator
    was the difference between "hey, this works" and <boom>. The code
    is https://github.com/dgryski/trifles/blob/master/udprelay/main.go

    Given the benchmarks listed here, it would be interesting to retry the
    relay with 1.6, perhaps using sync.Pool.

    Damian

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Voidlogic at Feb 29, 2016 at 3:05 pm
    Another option is to use *both* sync.Pool and one of these allocators by
    supplying the allocator as sync.Pool.New. I have a strong feeling this will
    out perform the non-hybrid approaches due to sync.Pools thread local
    storage and when allocation is actually needed, it will be faster.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedFeb 28, '16 at 10:56a
activeFeb 29, '16 at 3:05p
posts14
users9
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase