|
|
Descriptionbufio: Reader shortcuts to ReadFrom(). Writer shortcuts to b.wr.ReadFrom() if first read doesn't fill buffer.
Fixes issue 6373.
Patch Set 1 #Patch Set 2 : diff -r ec4ec27f4756 https://code.google.com/p/go #Patch Set 3 : diff -r ec4ec27f4756 https://code.google.com/p/go #
Total comments: 1
MessagesTotal messages: 11
Hello golang-codereviews@googlegroups.com, I'd like you to review this change to https://code.google.com/p/go
Sign in to reply to this message.
I would expect test additions, and/or a benchmark result. On Thu, Jan 16, 2014 at 5:50 PM, <pongad@gmail.com> wrote: > Reviewers: golang-codereviews, > > Message: > Hello golang-codereviews@googlegroups.com, > > I'd like you to review this change to > https://code.google.com/p/go > > > Description: > bufio: Reader shortcuts to ReadFrom(). Writer shortcuts to > b.wr.ReadFrom() if first read doesn't fill buffer. > > Fixes issue 6373. > > Please review this at https://codereview.appspot.com/53560043/ > > Affected files (+42, -12 lines): > M src/pkg/bufio/bufio.go > > > Index: src/pkg/bufio/bufio.go > =================================================================== > --- a/src/pkg/bufio/bufio.go > +++ b/src/pkg/bufio/bufio.go > @@ -410,6 +410,12 @@ > return n, err > } > > + if w, ok := w.(io.ReaderFrom); ok { > + m, err := w.ReadFrom(b.rd) > + n += m > + return n, err > + } > + > for b.fill(); b.r < b.w; b.fill() { > m, err := b.writeBuf(w) > n += m > @@ -607,12 +613,44 @@ > > // ReadFrom implements io.ReaderFrom. > func (b *Writer) ReadFrom(r io.Reader) (n int64, err error) { > - if b.Buffered() == 0 { > - if w, ok := b.wr.(io.ReaderFrom); ok { > - return w.ReadFrom(r) > + defer func() { > + if err == io.EOF { > + // If the buffer is full, we flush it > pre-emptively. > + if b.Available() == 0 { > + err = b.flush() > + } else { > + err = nil > + } > + } > + }() > + > + var m int > + if w, ok := b.wr.(io.ReaderFrom); ok { > + if b.Available() == 0 { > + if err1 := b.flush(); err1 != nil { > + return n, err1 > + } > + } > + m, err = r.Read(b.buf[b.n:]) > + if m == 0 { > + return > + } > + b.n += m > + n += int64(m) > + if err != nil { > + return > + } > + if b.Available() == 0 { > + if err1 := b.flush(); err1 != nil { > + return n, err1 > + } > + var m64 int64 > + m64, err = w.ReadFrom(r) > + n += m64 > + return n, err > } > } > - var m int > + > for { > if b.Available() == 0 { > if err1 := b.flush(); err1 != nil { > @@ -629,14 +667,6 @@ > break > } > } > - if err == io.EOF { > - // If we filled the buffer exactly, flush pre-emptively. > - if b.Available() == 0 { > - err = b.flush() > - } else { > - err = nil > - } > - } > return n, err > } > > > > -- > You received this message because you are subscribed to the Google Groups > "golang-codereviews" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-codereviews+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. >
Sign in to reply to this message.
https://codereview.appspot.com/53560043/diff/40001/src/pkg/bufio/bufio.go File src/pkg/bufio/bufio.go (right): https://codereview.appspot.com/53560043/diff/40001/src/pkg/bufio/bufio.go#new... src/pkg/bufio/bufio.go:616: defer func() { does this need to be a defer with a closure? if you're doing this CL for performance reasons, this addition seems surprising. do you have before/after numbers for any cases?
Sign in to reply to this message.
On 2014/01/17 01:58:41, bradfitz wrote: > https://codereview.appspot.com/53560043/diff/40001/src/pkg/bufio/bufio.go > File src/pkg/bufio/bufio.go (right): > > https://codereview.appspot.com/53560043/diff/40001/src/pkg/bufio/bufio.go#new... > src/pkg/bufio/bufio.go:616: defer func() { > does this need to be a defer with a closure? if you're doing this CL for > performance reasons, this addition seems surprising. > > do you have before/after numbers for any cases? You are right, of course. Sorry, I'm really new to the community and stdlib writing in general. Benchmark result below: ### After ### BenchmarkReaderCopyOptimal 1000000 1334 ns/op BenchmarkReaderCopyUnoptimal 200000 8346 ns/op BenchmarkReaderCopyNoWriteTo 100000 19996 ns/op BenchmarkWriterCopyOptimal 1000000 2441 ns/op BenchmarkWriterCopyUnoptimal 200000 8023 ns/op BenchmarkWriterCopyNoReadFrom 100000 20526 ns/op BenchmarkReaderEmpty 1000000 2268 ns/op 4224 B/op 3 allocs/op BenchmarkWriterEmpty 1000000 2292 ns/op 4160 B/op 2 allocs/op BenchmarkWriterFlush 100000000 20.1 ns/op 0 B/op 0 allocs/op ok bufio 54.426s ### Before ### BenchmarkReaderCopyOptimal 1000000 1410 ns/op BenchmarkReaderCopyUnoptimal 200000 8813 ns/op BenchmarkReaderCopyNoWriteTo 100000 21345 ns/op BenchmarkWriterCopyOptimal 200000 15005 ns/op BenchmarkWriterCopyUnoptimal 200000 8229 ns/op BenchmarkWriterCopyNoReadFrom 100000 21385 ns/op BenchmarkReaderEmpty 1000000 2309 ns/op 4224 B/op 3 allocs/op BenchmarkWriterEmpty 1000000 2302 ns/op 4160 B/op 2 allocs/op BenchmarkWriterFlush 100000000 20.1 ns/op 0 B/op 0 allocs/op ok bufio 42.310s I'm not quite sure how BenchmarkWriterCopyOptimal got so much faster. It looks like nothing got slower though. The reason I used defer was that the block crops up in so many places. I can use goto instead, though I'm not sure how people feel about that. Do you have any suggestions? Michael
Sign in to reply to this message.
Protip: $GOROOT/misc/benchcmp before.txt after.txt On Fri, Jan 17, 2014 at 1:35 PM, <pongad@gmail.com> wrote: > On 2014/01/17 01:58:41, bradfitz wrote: > > https://codereview.appspot.com/53560043/diff/40001/src/pkg/bufio/bufio.go > >> File src/pkg/bufio/bufio.go (right): >> > > > https://codereview.appspot.com/53560043/diff/40001/src/ > pkg/bufio/bufio.go#newcode616 > >> src/pkg/bufio/bufio.go:616: defer func() { >> does this need to be a defer with a closure? if you're doing this CL >> > for > >> performance reasons, this addition seems surprising. >> > > do you have before/after numbers for any cases? >> > > You are right, of course. Sorry, I'm really new to the community and > stdlib writing in general. Benchmark result below: > ### After ### > BenchmarkReaderCopyOptimal 1000000 1334 ns/op > BenchmarkReaderCopyUnoptimal 200000 8346 ns/op > BenchmarkReaderCopyNoWriteTo 100000 19996 ns/op > BenchmarkWriterCopyOptimal 1000000 2441 ns/op > BenchmarkWriterCopyUnoptimal 200000 8023 ns/op > BenchmarkWriterCopyNoReadFrom 100000 20526 ns/op > BenchmarkReaderEmpty 1000000 2268 ns/op 4224 > B/op 3 > allocs/op > BenchmarkWriterEmpty 1000000 2292 ns/op 4160 > B/op 2 > allocs/op > BenchmarkWriterFlush 100000000 20.1 ns/op 0 > B/op 0 > allocs/op > ok bufio 54.426s > > ### Before ### > BenchmarkReaderCopyOptimal 1000000 1410 ns/op > BenchmarkReaderCopyUnoptimal 200000 8813 ns/op > BenchmarkReaderCopyNoWriteTo 100000 21345 ns/op > BenchmarkWriterCopyOptimal 200000 15005 ns/op > BenchmarkWriterCopyUnoptimal 200000 8229 ns/op > BenchmarkWriterCopyNoReadFrom 100000 21385 ns/op > BenchmarkReaderEmpty 1000000 2309 ns/op 4224 > B/op 3 > allocs/op > BenchmarkWriterEmpty 1000000 2302 ns/op 4160 > B/op 2 > allocs/op > BenchmarkWriterFlush 100000000 20.1 ns/op 0 > B/op 0 > allocs/op > ok bufio 42.310s > > I'm not quite sure how BenchmarkWriterCopyOptimal got so much faster. It > looks like nothing got slower though. > The reason I used defer was that the block crops up in so many places. I > can use goto instead, though I'm not sure how people feel about that. Do > you have any suggestions? > > Michael > > > https://codereview.appspot.com/53560043/ > > -- > You received this message because you are subscribed to the Google Groups > "golang-codereviews" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-codereviews+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. >
Sign in to reply to this message.
Newbie response: benchmark old ns/op new ns/op delta BenchmarkReaderCopyOptimal 1410 1334 -5.39% BenchmarkReaderCopyUnoptimal 8813 8346 -5.30% BenchmarkReaderCopyNoWriteTo 21345 19996 -6.32% BenchmarkWriterCopyOptimal 15005 2441 -83.73% BenchmarkWriterCopyUnoptimal 8229 8023 -2.50% BenchmarkWriterCopyNoReadFrom 21385 20526 -4.02% BenchmarkReaderEmpty 2309 2268 -1.78% BenchmarkWriterEmpty 2302 2292 -0.43% BenchmarkWriterFlush 20 20 +0.00% benchmark old allocs new allocs delta BenchmarkReaderEmpty 3 3 0.00% BenchmarkWriterEmpty 2 2 0.00% BenchmarkWriterFlush 0 0 n/a% benchmark old bytes new bytes delta BenchmarkReaderEmpty 4224 4224 0.00% BenchmarkWriterEmpty 4160 4160 0.00% BenchmarkWriterFlush 0 0 n/a% On 2014/01/17 02:47:31, dfc wrote: > Protip: $GOROOT/misc/benchcmp before.txt after.txt > > > On Fri, Jan 17, 2014 at 1:35 PM, <mailto:pongad@gmail.com> wrote: > > > On 2014/01/17 01:58:41, bradfitz wrote: > > > > https://codereview.appspot.com/53560043/diff/40001/src/pkg/bufio/bufio.go > > > >> File src/pkg/bufio/bufio.go (right): > >> > > > > > > https://codereview.appspot.com/53560043/diff/40001/src/ > > pkg/bufio/bufio.go#newcode616 > > > >> src/pkg/bufio/bufio.go:616: defer func() { > >> does this need to be a defer with a closure? if you're doing this CL > >> > > for > > > >> performance reasons, this addition seems surprising. > >> > > > > do you have before/after numbers for any cases? > >> > > > > You are right, of course. Sorry, I'm really new to the community and > > stdlib writing in general. Benchmark result below: > > ### After ### > > BenchmarkReaderCopyOptimal 1000000 1334 ns/op > > BenchmarkReaderCopyUnoptimal 200000 8346 ns/op > > BenchmarkReaderCopyNoWriteTo 100000 19996 ns/op > > BenchmarkWriterCopyOptimal 1000000 2441 ns/op > > BenchmarkWriterCopyUnoptimal 200000 8023 ns/op > > BenchmarkWriterCopyNoReadFrom 100000 20526 ns/op > > BenchmarkReaderEmpty 1000000 2268 ns/op 4224 > > B/op 3 > > allocs/op > > BenchmarkWriterEmpty 1000000 2292 ns/op 4160 > > B/op 2 > > allocs/op > > BenchmarkWriterFlush 100000000 20.1 ns/op 0 > > B/op 0 > > allocs/op > > ok bufio 54.426s > > > > ### Before ### > > BenchmarkReaderCopyOptimal 1000000 1410 ns/op > > BenchmarkReaderCopyUnoptimal 200000 8813 ns/op > > BenchmarkReaderCopyNoWriteTo 100000 21345 ns/op > > BenchmarkWriterCopyOptimal 200000 15005 ns/op > > BenchmarkWriterCopyUnoptimal 200000 8229 ns/op > > BenchmarkWriterCopyNoReadFrom 100000 21385 ns/op > > BenchmarkReaderEmpty 1000000 2309 ns/op 4224 > > B/op 3 > > allocs/op > > BenchmarkWriterEmpty 1000000 2302 ns/op 4160 > > B/op 2 > > allocs/op > > BenchmarkWriterFlush 100000000 20.1 ns/op 0 > > B/op 0 > > allocs/op > > ok bufio 42.310s > > > > I'm not quite sure how BenchmarkWriterCopyOptimal got so much faster. It > > looks like nothing got slower though. > > The reason I used defer was that the block crops up in so many places. I > > can use goto instead, though I'm not sure how people feel about that. Do > > you have any suggestions? > > > > Michael > > > > > > https://codereview.appspot.com/53560043/ > > > > -- > > You received this message because you are subscribed to the Google Groups > > "golang-codereviews" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to mailto:golang-codereviews+unsubscribe@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > >
Sign in to reply to this message.
Nice work On Fri, Jan 17, 2014 at 2:01 PM, <pongad@gmail.com> wrote: > Newbie response: > benchmark old ns/op new ns/op delta > BenchmarkReaderCopyOptimal 1410 1334 -5.39% > BenchmarkReaderCopyUnoptimal 8813 8346 -5.30% > BenchmarkReaderCopyNoWriteTo 21345 19996 -6.32% > BenchmarkWriterCopyOptimal 15005 2441 -83.73% > BenchmarkWriterCopyUnoptimal 8229 8023 -2.50% > BenchmarkWriterCopyNoReadFrom 21385 20526 -4.02% > BenchmarkReaderEmpty 2309 2268 -1.78% > BenchmarkWriterEmpty 2302 2292 -0.43% > BenchmarkWriterFlush 20 20 +0.00% > > benchmark old allocs new allocs delta > BenchmarkReaderEmpty 3 3 0.00% > BenchmarkWriterEmpty 2 2 0.00% > BenchmarkWriterFlush 0 0 n/a% > > benchmark old bytes new bytes delta > BenchmarkReaderEmpty 4224 4224 0.00% > BenchmarkWriterEmpty 4160 4160 0.00% > BenchmarkWriterFlush 0 0 n/a% > > > > On 2014/01/17 02:47:31, dfc wrote: > >> Protip: $GOROOT/misc/benchcmp before.txt after.txt >> > > > On Fri, Jan 17, 2014 at 1:35 PM, <mailto:pongad@gmail.com> wrote: >> > > > On 2014/01/17 01:58:41, bradfitz wrote: >> > >> > >> > https://codereview.appspot.com/53560043/diff/40001/src/pkg/bufio/bufio.go > >> > >> >> File src/pkg/bufio/bufio.go (right): >> >> >> > >> > >> > https://codereview.appspot.com/53560043/diff/40001/src/ >> > pkg/bufio/bufio.go#newcode616 >> > >> >> src/pkg/bufio/bufio.go:616: defer func() { >> >> does this need to be a defer with a closure? if you're doing this >> > CL > >> >> >> > for >> > >> >> performance reasons, this addition seems surprising. >> >> >> > >> > do you have before/after numbers for any cases? >> >> >> > >> > You are right, of course. Sorry, I'm really new to the community and >> > stdlib writing in general. Benchmark result below: >> > ### After ### >> > BenchmarkReaderCopyOptimal 1000000 1334 ns/op >> > BenchmarkReaderCopyUnoptimal 200000 8346 ns/op >> > BenchmarkReaderCopyNoWriteTo 100000 19996 ns/op >> > BenchmarkWriterCopyOptimal 1000000 2441 ns/op >> > BenchmarkWriterCopyUnoptimal 200000 8023 ns/op >> > BenchmarkWriterCopyNoReadFrom 100000 20526 ns/op >> > BenchmarkReaderEmpty 1000000 2268 ns/op >> > 4224 > >> > B/op 3 >> > allocs/op >> > BenchmarkWriterEmpty 1000000 2292 ns/op >> > 4160 > >> > B/op 2 >> > allocs/op >> > BenchmarkWriterFlush 100000000 20.1 ns/op >> > 0 > >> > B/op 0 >> > allocs/op >> > ok bufio 54.426s >> > >> > ### Before ### >> > BenchmarkReaderCopyOptimal 1000000 1410 ns/op >> > BenchmarkReaderCopyUnoptimal 200000 8813 ns/op >> > BenchmarkReaderCopyNoWriteTo 100000 21345 ns/op >> > BenchmarkWriterCopyOptimal 200000 15005 ns/op >> > BenchmarkWriterCopyUnoptimal 200000 8229 ns/op >> > BenchmarkWriterCopyNoReadFrom 100000 21385 ns/op >> > BenchmarkReaderEmpty 1000000 2309 ns/op >> > 4224 > >> > B/op 3 >> > allocs/op >> > BenchmarkWriterEmpty 1000000 2302 ns/op >> > 4160 > >> > B/op 2 >> > allocs/op >> > BenchmarkWriterFlush 100000000 20.1 ns/op >> > 0 > >> > B/op 0 >> > allocs/op >> > ok bufio 42.310s >> > >> > I'm not quite sure how BenchmarkWriterCopyOptimal got so much >> > faster. It > >> > looks like nothing got slower though. >> > The reason I used defer was that the block crops up in so many >> > places. I > >> > can use goto instead, though I'm not sure how people feel about >> > that. Do > >> > you have any suggestions? >> > >> > Michael >> > >> > >> > https://codereview.appspot.com/53560043/ >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups > >> > "golang-codereviews" group. >> > To unsubscribe from this group and stop receiving emails from it, >> > send an > >> > email to mailto:golang-codereviews+unsubscribe@googlegroups.com. >> >> > For more options, visit https://groups.google.com/groups/opt_out. >> > >> > > > > https://codereview.appspot.com/53560043/ >
Sign in to reply to this message.
Also implemented with goto instead of defer. Does everyone like goto better? If so, I'll update the CL. Benchmark pasted below. michael@ubuntu:~/Desktop$ $GOROOT/misc/benchcmp before.txt goto.txt benchmark old ns/op new ns/op delta BenchmarkReaderCopyOptimal 1410 1378 -2.27% BenchmarkReaderCopyUnoptimal 8813 8671 -1.61% BenchmarkReaderCopyNoWriteTo 21345 11798 -44.73% BenchmarkWriterCopyOptimal 15005 2270 -84.87% BenchmarkWriterCopyUnoptimal 8229 8228 -0.01% BenchmarkWriterCopyNoReadFrom 21385 11943 -44.15% BenchmarkReaderEmpty 2309 2261 -2.08% BenchmarkWriterEmpty 2302 2263 -1.69% BenchmarkWriterFlush 20 20 +0.00% benchmark old allocs new allocs delta BenchmarkReaderEmpty 3 3 0.00% BenchmarkWriterEmpty 2 2 0.00% BenchmarkWriterFlush 0 0 n/a% benchmark old bytes new bytes delta BenchmarkReaderEmpty 4224 4224 0.00% BenchmarkWriterEmpty 4160 4160 0.00% BenchmarkWriterFlush 0 0 n/a% michael@ubuntu:~/Desktop$ $GOROOT/misc/benchcmp defer.txt goto.txt benchmark old ns/op new ns/op delta BenchmarkReaderCopyOptimal 1334 1378 +3.30% BenchmarkReaderCopyUnoptimal 8346 8671 +3.89% BenchmarkReaderCopyNoWriteTo 19996 11798 -41.00% BenchmarkWriterCopyOptimal 2441 2270 -7.01% BenchmarkWriterCopyUnoptimal 8023 8228 +2.56% BenchmarkWriterCopyNoReadFrom 20526 11943 -41.82% BenchmarkReaderEmpty 2268 2261 -0.31% BenchmarkWriterEmpty 2292 2263 -1.27% BenchmarkWriterFlush 20 20 +0.00% benchmark old allocs new allocs delta BenchmarkReaderEmpty 3 3 0.00% BenchmarkWriterEmpty 2 2 0.00% BenchmarkWriterFlush 0 0 n/a% benchmark old bytes new bytes delta BenchmarkReaderEmpty 4224 4224 0.00% BenchmarkWriterEmpty 4160 4160 0.00% BenchmarkWriterFlush 0 0 n/a% On 2014/01/17 03:08:06, dfc wrote: > Nice work > > > On Fri, Jan 17, 2014 at 2:01 PM, <mailto:pongad@gmail.com> wrote: > > > Newbie response: > > benchmark old ns/op new ns/op delta > > BenchmarkReaderCopyOptimal 1410 1334 -5.39% > > BenchmarkReaderCopyUnoptimal 8813 8346 -5.30% > > BenchmarkReaderCopyNoWriteTo 21345 19996 -6.32% > > BenchmarkWriterCopyOptimal 15005 2441 -83.73% > > BenchmarkWriterCopyUnoptimal 8229 8023 -2.50% > > BenchmarkWriterCopyNoReadFrom 21385 20526 -4.02% > > BenchmarkReaderEmpty 2309 2268 -1.78% > > BenchmarkWriterEmpty 2302 2292 -0.43% > > BenchmarkWriterFlush 20 20 +0.00% > > > > benchmark old allocs new allocs delta > > BenchmarkReaderEmpty 3 3 0.00% > > BenchmarkWriterEmpty 2 2 0.00% > > BenchmarkWriterFlush 0 0 n/a% > > > > benchmark old bytes new bytes delta > > BenchmarkReaderEmpty 4224 4224 0.00% > > BenchmarkWriterEmpty 4160 4160 0.00% > > BenchmarkWriterFlush 0 0 n/a% > > > > > > > > On 2014/01/17 02:47:31, dfc wrote: > > > >> Protip: $GOROOT/misc/benchcmp before.txt after.txt > >> > > > > > > On Fri, Jan 17, 2014 at 1:35 PM, <mailto:pongad@gmail.com> wrote: > >> > > > > > On 2014/01/17 01:58:41, bradfitz wrote: > >> > > >> > > >> > > https://codereview.appspot.com/53560043/diff/40001/src/pkg/bufio/bufio.go > > > >> > > >> >> File src/pkg/bufio/bufio.go (right): > >> >> > >> > > >> > > >> > https://codereview.appspot.com/53560043/diff/40001/src/ > >> > pkg/bufio/bufio.go#newcode616 > >> > > >> >> src/pkg/bufio/bufio.go:616: defer func() { > >> >> does this need to be a defer with a closure? if you're doing this > >> > > CL > > > >> >> > >> > for > >> > > >> >> performance reasons, this addition seems surprising. > >> >> > >> > > >> > do you have before/after numbers for any cases? > >> >> > >> > > >> > You are right, of course. Sorry, I'm really new to the community and > >> > stdlib writing in general. Benchmark result below: > >> > ### After ### > >> > BenchmarkReaderCopyOptimal 1000000 1334 ns/op > >> > BenchmarkReaderCopyUnoptimal 200000 8346 ns/op > >> > BenchmarkReaderCopyNoWriteTo 100000 19996 ns/op > >> > BenchmarkWriterCopyOptimal 1000000 2441 ns/op > >> > BenchmarkWriterCopyUnoptimal 200000 8023 ns/op > >> > BenchmarkWriterCopyNoReadFrom 100000 20526 ns/op > >> > BenchmarkReaderEmpty 1000000 2268 ns/op > >> > > 4224 > > > >> > B/op 3 > >> > allocs/op > >> > BenchmarkWriterEmpty 1000000 2292 ns/op > >> > > 4160 > > > >> > B/op 2 > >> > allocs/op > >> > BenchmarkWriterFlush 100000000 20.1 ns/op > >> > > 0 > > > >> > B/op 0 > >> > allocs/op > >> > ok bufio 54.426s > >> > > >> > ### Before ### > >> > BenchmarkReaderCopyOptimal 1000000 1410 ns/op > >> > BenchmarkReaderCopyUnoptimal 200000 8813 ns/op > >> > BenchmarkReaderCopyNoWriteTo 100000 21345 ns/op > >> > BenchmarkWriterCopyOptimal 200000 15005 ns/op > >> > BenchmarkWriterCopyUnoptimal 200000 8229 ns/op > >> > BenchmarkWriterCopyNoReadFrom 100000 21385 ns/op > >> > BenchmarkReaderEmpty 1000000 2309 ns/op > >> > > 4224 > > > >> > B/op 3 > >> > allocs/op > >> > BenchmarkWriterEmpty 1000000 2302 ns/op > >> > > 4160 > > > >> > B/op 2 > >> > allocs/op > >> > BenchmarkWriterFlush 100000000 20.1 ns/op > >> > > 0 > > > >> > B/op 0 > >> > allocs/op > >> > ok bufio 42.310s > >> > > >> > I'm not quite sure how BenchmarkWriterCopyOptimal got so much > >> > > faster. It > > > >> > looks like nothing got slower though. > >> > The reason I used defer was that the block crops up in so many > >> > > places. I > > > >> > can use goto instead, though I'm not sure how people feel about > >> > > that. Do > > > >> > you have any suggestions? > >> > > >> > Michael > >> > > >> > > >> > https://codereview.appspot.com/53560043/ > >> > > >> > -- > >> > You received this message because you are subscribed to the Google > >> > > Groups > > > >> > "golang-codereviews" group. > >> > To unsubscribe from this group and stop receiving emails from it, > >> > > send an > > > >> > email to mailto:golang-codereviews+unsubscribe@googlegroups.com. > >> > >> > For more options, visit https://groups.google.com/groups/opt_out. > >> > > >> > > > > > > > > https://codereview.appspot.com/53560043/ > >
Sign in to reply to this message.
For lack of activity here, I've sent off the simple part of this as https://codereview.appspot.com/69220046/ If you'd like to work on just the latter half in this CL and update the CL description and benchmarks, please do it soon. The tree is closing soon.
Sign in to reply to this message.
I'm currently swamped with schoolwork, so I won't be able to get to it in any reasonable time. I'll be willing to pick it up again after my schedule clears up a little bit. Probably after the tree closes and reopens, if no one has gotten to it by then. On 2014/02/27 07:57:01, bradfitz wrote: > For lack of activity here, I've sent off the simple part of this as > https://codereview.appspot.com/69220046/ > > If you'd like to work on just the latter half in this CL and update the CL > description and benchmarks, please do it soon. The tree is closing soon.
Sign in to reply to this message.
|