bytes.NewBuffer(nil) vs var buf bytes.Buffer

[Erik Unger]

I noticed that bytes.NewBuffer(nil) is used a lot in Go's standard
packages.

Wouldn't it be more efficient to use var buf bytes.Buffer and then
&buf in cases where the buffer is only used locally to avoid dynamic
memory allocations?

Or does the go compiler optimize that away?

-Erik

[Jessta]

On Sun, Feb 5, 2012 at 11:09 PM, Erik Unger <ung...@gmail.com> wrote:
> I noticed that bytes.NewBuffer(nil) is used a lot in Go's standard
> packages.
> Wouldn't it be more efficient to use var buf bytes.Buffer and then
> &buf in cases where the buffer is only used locally to avoid dynamic
> memory allocations?

bytes.NewBuffer() should only be used to prepare a buffer for reading
from or to make the buffer a specific size.
bytes.NewBuffer(nil) is exactly the same as &bytes.Buffer{} so it's weird that
this appears in the stdlib.

> Or does the go compiler optimize that away?

The compiler would, but it's still kind of silly.

- jessta

--
=====================
http://jessta.id.au

[Andrew Gerrand]

On Sunday, February 5, 2012 11:09:20 PM UTC+11, Erik Unger wrote:

I noticed that bytes.NewBuffer(nil) is used a lot in Go's standard
packages.

Actually there are only a handful of occurrences of that form. Mostly we either use the "var buf bytes.Buffer" form, or "buf := new(bytes.Buffer)". There's no tangible performance benefit to any of the approaches.

"var [a-z]+ bytes.Buffer"

  http://weekly.golang.org/search?q=var+%5Ba-z%5D%2B+bytes.Buffer

"new(bytes.Buffer)"

  http://weekly.golang.org/search?q=new%5C%28bytes.Buffer%5C%29

By the looks of it, it's Nigel who mostly favours "NewBuffer(nil)". He's special. ;-)

"NewBuffer(nil)"

  http://weekly.golang.org/search?q=NewBuffer%5C%28nil%5C%29

Andrew

[⚛]

On Feb 5, 2:11 pm, Jessta <jes...@jessta.id.au> wrote:

> On Sun, Feb 5, 2012 at 11:09 PM, Erik Unger <unge...@gmail.com> wrote:
> > Or does the go compiler optimize that away?
>
> The compiler would, but it's still kind of silly.

I wouldn't be silly in an optimizing compiler.

[roger peppe]

Quite right too. Optimizing compilers look very sternly on
silly behaviour in their innards.

[⚛]

Correction: It wouldn't be silly in an optimizing compiler.

[⚛]

On Feb 6, 11:26 am, roger peppe <rogpe...@gmail.com> wrote:

What do you mean?

[roger peppe]

just being silly with your spelling mistake... :-)

[Russ Cox]

On Mon, Feb 6, 2012 at 06:15, ⚛ <0xe2.0x...@gmail.com> wrote:
> Correction: It wouldn't be silly in an optimizing compiler.

It is still best to write the simplest, clearest code you can.
Writing unnecessarily complex or inefficient code and leaving
it for the compiler to clean up is not a winning strategy.
http://prog21.dadgum.com/40.html

Russ