[go-nuts] Data: How many cases do selects usually have?

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

     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

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.

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

     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

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