FAQ
Hi all,

In case you were ever curious...I gathered some data about how many
cases select statements usually have, based on godoc.org-listed
packages. It's in the big, obvious table at
https://github.com/josharian/countselectcases.

No great surprises. Some tidbits:

* Over 75% of selects are either 1 communication case and a default
case or 2 communication cases.
* ~1.5% selects are used to park the goroutine (i.e. select{}).
* ~5.5% could be removed entirely, due to having exactly one case.
* The largest number of cases is 14(!).

Caveat lector, of course.

As long as I've got this corpus downloaded...anyone have ideas for
other interesting stats to look at?

-josh

--
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/groups/opt_out.

Search Discussions

  • Andrew Gerrand at Sep 26, 2013 at 2:13 am
    Count how many files are gofmt'd. Last time I checked it was around 70%.
    I'd be interested to see if the number changed.

    --
    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/groups/opt_out.
  • Josh Bleecher Snyder at Sep 26, 2013 at 2:48 am

    Count how many files are gofmt'd. Last time I checked it was around 70%. I'd
    be interested to see if the number changed.
    Good idea.

    I started with the crude/obvious thing:

    $ find . -name "*.go" > filelist.txt
    $ wc -l filelist.txt
        80388 filelist.txt
    $ for f in `cat filelist.txt`; do gofmt -l $f; done | | wc -l
    18304

    That's ~14% not gofmt'd. (There were also 668 lines of errors written
    to stderr.)

    However, I noticed some funny things show up in the "not formatted"
    list, like code.google.com/p/go/src/pkg/net/rpc/client.go -- which is
    *definitely* well-formatted. I think go get might have gotten a very
    old copy of the stdlib. Also, there are a lot of tests in the go repo
    with intentionally non-formatted code.

    I can try harder to get an accurate number if you'd like, but based on
    this very quick cut, I'd say at least 85% is now well-formatted, and
    probably a good sight higher.

    -josh

    --
    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/groups/opt_out.
  • John Nagle at Sep 26, 2013 at 2:28 am

    On 9/25/2013 7:06 PM, Josh Bleecher Snyder wrote:
    Hi all,

    In case you were ever curious...I gathered some data about how many
    cases select statements usually have, based on godoc.org-listed
    packages. It's in the big, obvious table at
    https://github.com/josharian/countselectcases.
         Which selects are handled by compiled code? I think
    the single-wait case is handled by compiled code. At
    some point, the compiler just turns the problem over to
    a library routine for a general N-way wait. But what's
    the threshold for that?

         The N-way case, in the library, is incredibly complicated and
    the code, which loops through the whole list several times
    and does memory allocations, looks slow. It's probably
    desirable to avoid invoking that in frequently used code.

         John Nagle

    --
    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/groups/opt_out.
  • Josh Bleecher Snyder at Sep 26, 2013 at 2:52 am

    In case you were ever curious...I gathered some data about how many
    cases select statements usually have, based on godoc.org-listed
    packages. It's in the big, obvious table at
    https://github.com/josharian/countselectcases.
    Which selects are handled by compiled code? I think
    the single-wait case is handled by compiled code. At
    some point, the compiler just turns the problem over to
    a library routine for a general N-way wait. But what's
    the threshold for that?
    According to https://code.google.com/p/go/source/browse/src/pkg/runtime/chan.c#868:

    // The compiler rewrites selects that statically have
    // only 0 or 1 cases plus default into simpler constructs.

    And that is borne out in the relevant place in the compiler. Any
    select that has more than one communication cases at compile time goes
    through the general select code, regardless of how many cases happen
    to be active (non-nil) at the time.

    The N-way case, in the library, is incredibly complicated and
    the code, which loops through the whole list several times
    and does memory allocations, looks slow. It's probably
    desirable to avoid invoking that in frequently used code.
    Well, profile first and all that. That said, I had the same thought
    and took a stab at optimizing some pieces of it without profiling, for
    fun. :) See https://codereview.appspot.com/13948043/...definitely WIP,
    and maybe not a good idea net net.


    -josh

    --
    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/groups/opt_out.
  • John Nagle at Sep 26, 2013 at 3:06 am

    On 9/25/2013 7:51 PM, Josh Bleecher Snyder wrote:
    In case you were ever curious...I gathered some data about how many
    cases select statements usually have, based on godoc.org-listed
    packages. It's in the big, obvious table at
    https://github.com/josharian/countselectcases.
    Which selects are handled by compiled code? I think
    the single-wait case is handled by compiled code. At
    some point, the compiler just turns the problem over to
    a library routine for a general N-way wait. But what's
    the threshold for that?
    According to https://code.google.com/p/go/source/browse/src/pkg/runtime/chan.c#868:

    // The compiler rewrites selects that statically have
    // only 0 or 1 cases plus default into simpler constructs.

    And that is borne out in the relevant place in the compiler. Any
    select that has more than one communication cases at compile time goes
    through the general select code, regardless of how many cases happen
    to be active (non-nil) at the time.

    The N-way case, in the library, is incredibly complicated and
    the code, which loops through the whole list several times
    and does memory allocations, looks slow. It's probably
    desirable to avoid invoking that in frequently used code.
    Well, profile first and all that. That said, I had the same thought
    and took a stab at optimizing some pieces of it without profiling, for
    fun. :) See https://codereview.appspot.com/13948043/...definitely WIP,
    and maybe not a good idea net net.
         Looking at the stats, a special case for N=2 looks like a big win.
    N=2 is the most common case, by a factor of 10.
    N=1 is already handled, and N>2 cases aren't that common.

         John Nagle



    --
    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/groups/opt_out.
  • Josh Bleecher Snyder at Sep 26, 2013 at 3:14 am

    The N-way case, in the library, is incredibly complicated and
    the code, which loops through the whole list several times
    and does memory allocations, looks slow. It's probably
    desirable to avoid invoking that in frequently used code.
    Well, profile first and all that. That said, I had the same thought
    and took a stab at optimizing some pieces of it without profiling, for
    fun. :) See https://codereview.appspot.com/13948043/...definitely WIP,
    and maybe not a good idea net net.
    Looking at the stats, a special case for N=2 looks like a big win.
    N=2 is the most common case, by a factor of 10.
    N=1 is already handled, and N>2 cases aren't that common.
    N=1 is not entirely already handled -- IIUC, the relevant N here is
    how many cases are non-nil going in, as opposed to how many cases are
    present in the code.

    That said, yes, special-casing N=1 and N=2 seem like the biggest
    opportunities by far, and the code impact for special-casing them is
    minimal. I guess I kinda went crazy with the rest of it...having too
    much fun. :)

    -josh

    --
    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/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedSep 26, '13 at 2:07a
activeSep 26, '13 at 3:14a
posts7
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase