Most overhead comes from peers that connect that have everything, and we just increment every single piece's availability. There may be some unresolved determinism with torrents that share the same ordering.
Allow for certain values to always be properly initialized on construction -- namely the maps for now. I'm currently working on a change that requires a baseline constructor; this change would make the use of `chansync.BroadcastCond` and `chansync.SetOnce` obsolete -- i.e. one can have channel members without worrying about proper initialization/destruction of a `chan struct{}`.
As for why `makeClient` returns a value instead of a pointer: returning a value gives us more options -- you can always take a pointer from a value later on cheaply, and have things moved to the heap if they weren't already. The same can't be said about getting a value back from a pointer. GC also could potentially have less work to do. Plus I personally find ownership to be an important concept (semi-borrowed from rust) -- use of values make ownership clear.
* Drop bradfitz/iter dependency
`range iter.N` looks nice and doesn't allocate, but unfortunately using a `range` expression blocks a function from being inlined wherever it's used (for now). It's not that we need inlining in all cases, but I do think a C-style for loop looks just as nice and is probably clearer to the majority. There also aren't any clear disadvantages to changing (unless you just happen to dislike the look of C)
* Update misc_test.go
* Update rlreader_test.go
* Update torrent_test.go
* Update bench_test.go
* Update client_test.go
* Update iplist_test.go
* Update mse_test.go
* Update peerconn_test.go
* Update peerconn.go
* Update order_test.go
* Update decoder_test.go
* Update main.go
* Update bench-piece-mark-complete.go
* Update main.go
* Update torrent.go
* Update iplist_test.go
* Update main.go
Matt Joiner