FAQ
Sorry, the code example’s URL is not correct. It is here: http://play.golang.org/p/-V6zf9vefP

发件人: Zhang,Lei(Ecom)
发送时间: 2014年7月31日 22:52
收件人: 'golang-nuts@googlegroups.com'
主题: Gob performance problem in heavy concurrent use

Hello !

I am using gob to concurrently encode/decode data via network. But it seems that there is a bottleneck for the concurrent use of gob. Here is a code example that reproduces the problem: http://play.golang.org/p/W6X0yqdub9 . It simulates a concurrent decoding of large data sent over network by multiple goroutines. If you run the program, and then use the pprof tool to see the cpu usage, you may get something like this:

(pprof) top5
Total: 172 samples
       97 56.4% 56.4% 97 56.4% sync/atomic.AddUint32
        7 4.1% 60.5% 8 4.7% bytes.(*Buffer).WriteByte
        7 4.1% 64.5% 13 7.6% encoding/gob.(*decoderState).decodeUint
        7 4.1% 68.6% 7 4.1% runtime.memmove
        6 3.5% 72.1% 23 13.4% encoding/gob.encInt

Half of the time is spent on AddUint32. If you let pprof to focus on the function, you can see it is from the mutex lock calls in gob.validUserType function (in type.go file of the gob package). The attached file clearly shows this.

My question is: is there something wrong with my concurrent use of gob ? Or there is a way to reduce the bottleneck ? Thanks !

Lei

--
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

  • Carlos Castillo at Aug 1, 2014 at 2:57 am
    Are you profiling on OSX? If so, unless you've taken measures to resolve it
    CPU profiling is broken. See: http://research.swtch.com/macpprof

    On my machine, the highest CPU use is for gob.decInt64, which makes sense
    as it's decoding a lot of 64 bit integers, and decoding in this scenario is
    more expensive than encoding.

    On Thursday, July 31, 2014 7:56:43 AM UTC-7, Zhang,Lei(Ecom) wrote:

    Sorry, the code example’s URL is not correct. It is here:
    http://play.golang.org/p/-V6zf9vefP



    *发件人:* Zhang,Lei(Ecom)
    *发送时间:* 2014年7月31日 22:52
    *收件人:* 'golan...@googlegroups.com <javascript:>'
    *主题:* Gob performance problem in heavy concurrent use



    Hello !



    I am using gob to concurrently encode/decode data via network. But it
    seems that there is a bottleneck for the concurrent use of gob. Here is a
    code example that reproduces the problem:
    http://play.golang.org/p/W6X0yqdub9 . It simulates a concurrent decoding
    of large data sent over network by multiple goroutines. If you run the
    program, and then use the pprof tool to see the cpu usage, you may get
    something like this:



    (pprof) top5

    Total: 172 samples

    97 56.4% 56.4% 97 56.4% sync/atomic.AddUint32

    7 4.1% 60.5% 8 4.7% bytes.(*Buffer).WriteByte

    7 4.1% 64.5% 13 7.6%
    encoding/gob.(*decoderState).decodeUint

    7 4.1% 68.6% 7 4.1% runtime.memmove

    6 3.5% 72.1% 23 13.4% encoding/gob.encInt



    Half of the time is spent on AddUint32. If you let pprof to focus on the
    function, you can see it is from the mutex lock calls in gob.validUserType
    function (in type.go file of the gob package). The attached file clearly
    shows this.



    My question is: is there something wrong with my concurrent use of gob ?
    Or there is a way to reduce the bottleneck ? Thanks !



    Lei

    --
    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.
  • Zhang,Lei(Ecom) at Aug 1, 2014 at 6:25 am
    No, I am running and profiling the program on linux with AMD64 cpu. Ian has pointed out a similar discussion on the problem here: https://groups.google.com/d/msg/golang-dev/SBmIen68ys0/WGfYQQSO4nAJ

    It’s then surprising to know that the issue disappears on OSX.


    发件人: golang-nuts@googlegroups.com 代表 Carlos Castillo
    发送时间: 2014年8月1日 10:57
    收件人: golang-nuts@googlegroups.com
    主题: [go-nuts] Re: Gob performance problem in heavy concurrent use

    Are you profiling on OSX? If so, unless you've taken measures to resolve it CPU profiling is broken. See: http://research.swtch.com/macpprof

    On my machine, the highest CPU use is for gob.decInt64, which makes sense as it's decoding a lot of 64 bit integers, and decoding in this scenario is more expensive than encoding.


    On Thursday, July 31, 2014 7:56:43 AM UTC-7, Zhang,Lei(Ecom) wrote:
    Sorry, the code example’s URL is not correct. It is here: http://play.golang.org/p/-V6zf9vefP

    发件人: Zhang,Lei(Ecom)
    发送时间: 2014年7月31日 22:52
    收件人: 'golan...@googlegroups.com<javascript:>'
    主题: Gob performance problem in heavy concurrent use

    Hello !

    I am using gob to concurrently encode/decode data via network. But it seems that there is a bottleneck for the concurrent use of gob. Here is a code example that reproduces the problem: http://play.golang.org/p/W6X0yqdub9 . It simulates a concurrent decoding of large data sent over network by multiple goroutines. If you run the program, and then use the pprof tool to see the cpu usage, you may get something like this:

    (pprof) top5
    Total: 172 samples
           97 56.4% 56.4% 97 56.4% sync/atomic.AddUint32
            7 4.1% 60.5% 8 4.7% bytes.(*Buffer).WriteByte
            7 4.1% 64.5% 13 7.6% encoding/gob.(*decoderState).decodeUint
            7 4.1% 68.6% 7 4.1% runtime.memmove
            6 3.5% 72.1% 23 13.4% encoding/gob.encInt

    Half of the time is spent on AddUint32. If you let pprof to focus on the function, you can see it is from the mutex lock calls in gob.validUserType function (in type.go file of the gob package). The attached file clearly shows this.

    My question is: is there something wrong with my concurrent use of gob ? Or there is a way to reduce the bottleneck ? Thanks !

    Lei

    --
    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.
  • Carlos Castillo at Aug 1, 2014 at 9:44 am
    Actually, it's probably not an issue on my machine since my machine only
    has two cores (and no Hyperthreading).

    If the problem you are having is indeed caused by the shared access to the
    package-wide state in the gob package, I won't be able to reproduce it
    no-matter what I set GOMAXPROCS to.

    On Thu, Jul 31, 2014 at 11:24 PM, Zhang,Lei(Ecom) wrote:

    No, I am running and profiling the program on linux with AMD64 cpu. Ian
    has pointed out a similar discussion on the problem here:
    https://groups.google.com/d/msg/golang-dev/SBmIen68ys0/WGfYQQSO4nAJ



    It’s then surprising to know that the issue disappears on OSX.





    *发件人:* golang-nuts@googlegroups.com *代表
    *Carlos Castillo
    *发送时间:* 2014年8月1日 10:57
    *收件人:* golang-nuts@googlegroups.com
    *主题:* [go-nuts] Re: Gob performance problem in heavy concurrent use



    Are you profiling on OSX? If so, unless you've taken measures to resolve
    it CPU profiling is broken. See: http://research.swtch.com/macpprof

    On my machine, the highest CPU use is for gob.decInt64, which makes sense
    as it's decoding a lot of 64 bit integers, and decoding in this scenario is
    more expensive than encoding.




    On Thursday, July 31, 2014 7:56:43 AM UTC-7, Zhang,Lei(Ecom) wrote:

    Sorry, the code example’s URL is not correct. It is here:
    http://play.golang.org/p/-V6zf9vefP



    *发件人:* Zhang,Lei(Ecom)
    *发送时间:* 2014年7月31日 22:52
    *收件人:* 'golan...@googlegroups.com'
    *主题:* Gob performance problem in heavy concurrent use



    Hello !



    I am using gob to concurrently encode/decode data via network. But it
    seems that there is a bottleneck for the concurrent use of gob. Here is a
    code example that reproduces the problem:
    http://play.golang.org/p/W6X0yqdub9 . It simulates a concurrent decoding
    of large data sent over network by multiple goroutines. If you run the
    program, and then use the pprof tool to see the cpu usage, you may get
    something like this:



    (pprof) top5

    Total: 172 samples

    97 56.4% 56.4% 97 56.4% sync/atomic.AddUint32

    7 4.1% 60.5% 8 4.7% bytes.(*Buffer).WriteByte

    7 4.1% 64.5% 13 7.6%
    encoding/gob.(*decoderState).decodeUint

    7 4.1% 68.6% 7 4.1% runtime.memmove

    6 3.5% 72.1% 23 13.4% encoding/gob.encInt



    Half of the time is spent on AddUint32. If you let pprof to focus on the
    function, you can see it is from the mutex lock calls in gob.validUserType
    function (in type.go file of the gob package). The attached file clearly
    shows this.



    My question is: is there something wrong with my concurrent use of gob ?
    Or there is a way to reduce the bottleneck ? Thanks !



    Lei



    --
    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.

    --
    Carlos Castillo

    --
    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.
  • Matt Harden at Aug 1, 2014 at 10:31 pm
    I believe the problem is in the gob package, in this line:
    https://code.google.com/p/go/source/browse/src/pkg/encoding/gob/decode.go?name=release#903

    Notice that inside the closure, we call userType(typ), which then triggers
    the bottleneck. Note that we are already calling userType(typ) six lines
    above, outside of the closure. We should hold on to the result of that
    earlier call and use the resulting value in the closure. Then the number of
    calls to userType() in this example should go way down.

    On Fri, Aug 1, 2014 at 4:44 AM, Carlos Castillo wrote:

    Actually, it's probably not an issue on my machine since my machine only
    has two cores (and no Hyperthreading).

    If the problem you are having is indeed caused by the shared access to the
    package-wide state in the gob package, I won't be able to reproduce it
    no-matter what I set GOMAXPROCS to.

    On Thu, Jul 31, 2014 at 11:24 PM, Zhang,Lei(Ecom) wrote:

    No, I am running and profiling the program on linux with AMD64 cpu.
    Ian has pointed out a similar discussion on the problem here:
    https://groups.google.com/d/msg/golang-dev/SBmIen68ys0/WGfYQQSO4nAJ



    It’s then surprising to know that the issue disappears on OSX.





    *发件人:* golang-nuts@googlegroups.com
    *代表 *Carlos Castillo
    *发送时间:* 2014年8月1日 10:57
    *收件人:* golang-nuts@googlegroups.com
    *主题:* [go-nuts] Re: Gob performance problem in heavy concurrent use



    Are you profiling on OSX? If so, unless you've taken measures to resolve
    it CPU profiling is broken. See: http://research.swtch.com/macpprof

    On my machine, the highest CPU use is for gob.decInt64, which makes sense
    as it's decoding a lot of 64 bit integers, and decoding in this scenario is
    more expensive than encoding.




    On Thursday, July 31, 2014 7:56:43 AM UTC-7, Zhang,Lei(Ecom) wrote:

    Sorry, the code example’s URL is not correct. It is here:
    http://play.golang.org/p/-V6zf9vefP



    *发件人:* Zhang,Lei(Ecom)
    *发送时间:* 2014年7月31日 22:52
    *收件人:* 'golan...@googlegroups.com'
    *主题:* Gob performance problem in heavy concurrent use



    Hello !



    I am using gob to concurrently encode/decode data via network. But it
    seems that there is a bottleneck for the concurrent use of gob. Here is a
    code example that reproduces the problem:
    http://play.golang.org/p/W6X0yqdub9 . It simulates a concurrent decoding
    of large data sent over network by multiple goroutines. If you run the
    program, and then use the pprof tool to see the cpu usage, you may get
    something like this:



    (pprof) top5

    Total: 172 samples

    97 56.4% 56.4% 97 56.4% sync/atomic.AddUint32

    7 4.1% 60.5% 8 4.7% bytes.(*Buffer).WriteByte

    7 4.1% 64.5% 13 7.6%
    encoding/gob.(*decoderState).decodeUint

    7 4.1% 68.6% 7 4.1% runtime.memmove

    6 3.5% 72.1% 23 13.4% encoding/gob.encInt



    Half of the time is spent on AddUint32. If you let pprof to focus on the
    function, you can see it is from the mutex lock calls in gob.validUserType
    function (in type.go file of the gob package). The attached file clearly
    shows this.



    My question is: is there something wrong with my concurrent use of gob ?
    Or there is a way to reduce the bottleneck ? Thanks !



    Lei



    --
    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.

    --
    Carlos Castillo

    --
    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.
  • Rob Pike at Aug 3, 2014 at 9:35 pm
    Good catch. https://codereview.appspot.com/117520043

    -rob

    --
    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.
  • Hamish Ogilvy at Aug 2, 2014 at 9:50 pm
    Gob does a lot of magic for you, but depending on what you're doing you may
    not need it, there's many other ways to encode simple data that are more
    efficient. If it's just simple data, then look at other encoding
    alternatives first.

    On Thursday, 31 July 2014 07:56:43 UTC-7, Zhang,Lei(Ecom) wrote:

    Sorry, the code example’s URL is not correct. It is here:
    http://play.golang.org/p/-V6zf9vefP



    *发件人:* Zhang,Lei(Ecom)
    *发送时间:* 2014年7月31日 22:52
    *收件人:* 'golan...@googlegroups.com <javascript:>'
    *主题:* Gob performance problem in heavy concurrent use



    Hello !



    I am using gob to concurrently encode/decode data via network. But it
    seems that there is a bottleneck for the concurrent use of gob. Here is a
    code example that reproduces the problem:
    http://play.golang.org/p/W6X0yqdub9 . It simulates a concurrent decoding
    of large data sent over network by multiple goroutines. If you run the
    program, and then use the pprof tool to see the cpu usage, you may get
    something like this:



    (pprof) top5

    Total: 172 samples

    97 56.4% 56.4% 97 56.4% sync/atomic.AddUint32

    7 4.1% 60.5% 8 4.7% bytes.(*Buffer).WriteByte

    7 4.1% 64.5% 13 7.6%
    encoding/gob.(*decoderState).decodeUint

    7 4.1% 68.6% 7 4.1% runtime.memmove

    6 3.5% 72.1% 23 13.4% encoding/gob.encInt



    Half of the time is spent on AddUint32. If you let pprof to focus on the
    function, you can see it is from the mutex lock calls in gob.validUserType
    function (in type.go file of the gob package). The attached file clearly
    shows this.



    My question is: is there something wrong with my concurrent use of gob ?
    Or there is a way to reduce the bottleneck ? Thanks !



    Lei

    --
    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
postedJul 31, '14 at 2:56p
activeAug 3, '14 at 9:35p
posts7
users5
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase