Hacker News Reader

Comment by infogulch | Hacker News Reader

One thing that stood out to me is that allocations were reduced from 18-30 per op down to zero across the board. I'd be interested in the techniques they used to achieve this, and if any could be applied to the standard library itself. Also, a benchcmp would be nice.

View on HN

By the way, here is the benchcmp copied from the results in the README (and renaming them so benchcmp works properly), omitting allocs and bytes because that's already pretty clear. First, GOMAXPROCS=1:

    benchmark                                    old ns/op     new ns/op     delta
    BenchmarkServerGet1ReqPerConn                21211         2495          -88.24%
    BenchmarkServerGet2ReqPerConn                15682         1925          -87.72%
    BenchmarkServerGet10ReqPerConn               9957          1300          -86.94%
    BenchmarkServerGet10KReqPerConn              8243          1140          -86.17%
    BenchmarkServerGet1ReqPerConn1KClients       23474         2460          -89.52%
    BenchmarkServerGet2ReqPerConn1KClients       18124         1962          -89.17%
    BenchmarkServerGet10ReqPerConn1KClients      11815         1340          -88.66%
    BenchmarkServerGet10KReqPerConn1KClients     9106          1180          -87.04%

GOMAXPROCS=4:

    benchmark                                      old ns/op     new ns/op     delta
    BenchmarkServerGet1ReqPerConn-4                5929          1094          -81.55%
    BenchmarkServerGet2ReqPerConn-4                4153          707           -82.98%
    BenchmarkServerGet10ReqPerConn-4               2751          417           -84.84%
    BenchmarkServerGet10KReqPerConn-4              2398          351           -85.36%
    BenchmarkServerGet1ReqPerConn1KClients-4       5979          916           -84.68%
    BenchmarkServerGet2ReqPerConn1KClients-4       4582          655           -85.70%
    BenchmarkServerGet10ReqPerConn1KClients-4      3589          404           -88.74%
    BenchmarkServerGet10KReqPerConn1KClients-4     2465          359           -85.44%

sync.pools aka buffer pools.

this puts lots of back pressure on GC trading bursts of speed for a more noticeable pause at a later time bc of the pause-the-world style GC. I'd love to see if this is still the case with the GC improvements in Go 1.5+. One solution is to manually load balance your web services to switch seamlessly between GC pauses (stagnated gc), without this it's almost unusable in real time applications.

Yeah I thought sync.Pool might be involved. But I don't see how this would negatively impact the GC, since using a pool almost always reduces the amount of garbage.

Unlike in C you can't tell the garbage collector to "ignore" a large chunk of the memory allocated in the buffer. what ends up happening is Go's GC spends lots of time traversing the heap and marking anyway and end up doing nothing. I know they've made optimizations like here https://github.com/golang/go/issues/9477 but I haven't followed it up and gave it another look yet.

Reply on news.ycombinator.com