code review 176071: When the buffer is empty, reset b.off to the beginning ...

When the buffer is empty, reset b.off to the beginning of the buffer
to avoid growing unnecessarily.

[r, 2009-12-14 00:58:17]

Hello rsc (cc: golang-dev@googlegroups.com),

I'd like you to review the following change.

[rsc, 2009-12-14 02:09:45]

LGTM

[r, 2009-12-14 02:13:04]

*** Submitted as http://code.google.com/p/go/source/detail?r=765872a1c7ae ***

When the buffer is empty, reset b.off to the beginning of the buffer
to avoid growing unnecessarily.

R=rsc
CC=golang-dev
http://codereview.appspot.com/176071

[cw, 2009-12-14 06:28:08]

FWIW, when I submitted the shrink changes I had a version that did this and it
for the most part suffices quite well.

I'm happy to see this change.

One thing I notice is that it will truncate down to <64 bytes of storage when
even that could be released as we have the bootstrap space.

[rsc, 2009-12-14 06:35:52]

On Sun, Dec 13, 2009 at 22:28,  <cw@f00f.org> wrote:
> FWIW, when I submitted the shrink changes I had a version that did this
> and it for the most part suffices quite well.
>
> I'm happy to see this change.
>
> One thing I notice is that it will truncate down to <64 bytes of storage
> when even that could be released as we have the bootstrap space.

This change is only about reusing storage.
It is *not* about releasing memory.

Russ

[cw, 2009-12-14 06:44:16]

On Sun, Dec 13, 2009 at 10:35:49PM -0800, Russ Cox wrote:

> This change is only about reusing storage.
> It is *not* about releasing memory.

Ah, of course.

Nevertheless, for a 'make test' of src/pkg it's almost as good though
when I instrument it with a 'slack space checker' patch I have here.

In doing that I found I couldn't use fmt.Printf and friends (because
they themselves use bytes.Buffer?) so I open-coded the conversion
output routines.  When I tried strconv that failed in similar ways.

Was it really necessary I do that or perhaps I just hit some build
quirk?

[rsc, 2009-12-14 07:49:47]

> In doing that I found I couldn't use fmt.Printf and friends (because
> they themselves use bytes.Buffer?) so I open-coded the conversion
> output routines.  When I tried strconv that failed in similar ways.
>
> Was it really necessary I do that or perhaps I just hit some build
> quirk?

I assume you are importing fmt or strconv from package bytes?
That's not allowed, because both of those import bytes.
No cycles.

Russ

[cw, 2009-12-14 08:08:17]

On Sun, Dec 13, 2009 at 11:49:40PM -0800, Russ Cox wrote:

> I assume you are importing fmt or strconv from package bytes?
> That's not allowed, because both of those import bytes.
> No cycles.

right, which is why for debugging i have some quick and dirty itoa
functions i dropped in place to log directly to an os.File

i'm wondering if there is a better way

[rsc, 2009-12-14 08:50:12]

> right, which is why for debugging i have some quick and dirty itoa
> functions i dropped in place to log directly to an os.File
>
> i'm wondering if there is a better way

for debugging you can use the print builtin.

russ