cmd/compile: use strings.Builder

[josharian]

The main challenge here is ensuring everything still works when built with 1.4.

Probably build tag protected files, with something like

type buffer struct {
bytes.Buffer
}

for pre-1.10 and

type buffer = strings.Builder

for 1.10+.

[mdempsky]

I've been thinking we should add a "cmd/internal/polyfill" (or however we want to spell the bikeshed) package that provides interfaces to sort.Slice, strings.Builder, and other recent stdlib additions that we want to use in the toolchain, while maintaining Go 1.4 compatibility.

[bradfitz]

@mdempsky, you could call the package just "util". ducks

[davecheney]

Why stop there? “common”, “shared”, or “base” are all perfectly cromulent package names.

…

On 15 Feb 2018, at 07:09, Brad Fitzpatrick ***@***.***> wrote: @mdempsky, you could call the package just "util". ducks — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[martisch]

cmd/internal/compat?

[pciet]

In cmd/compile/internal/gc there's these cases:

• fmt.Fprintln/fmt.Fprintf writing to a bytes.Buffer
• bytes.Buffer plugged into the output of exec.Command
• buf.WriteString()
• buf.WriteString(fmt.Sprintf())
• bufio.NewWriter(&a_bytes.Buffer)

I assume there might be cases of “str” + “str2” or fmt.Sprintf that may be more efficient as a strings.Builder.

#18990 indicates there are no benchmarks for Builder. I see go tool compile -bench that would allow a comparison of compiler things in ns/op with these changes. Without a clear performance win I don't see a reason to do this.

[bradfitz]

In any case, the point behind my snark was to make sure that the package does NOT become a "util" package that itself depends on many things the caller of your package may not want.

It might be valid for the first few things, but it'll inevitably grow, and the util-ness bloat will sneak up on us.

It might be best to have N such packages under some "compat" or "future" directory.

[bradfitz]

@pciet, there are tests for Builder's allocations. Not allocating as much helps CPU, running the GC less. It's hard to capture that in benchmarks sometimes. (or they end up noisy)

[pciet]

cmd/internal/compat/strbuf? Isn't compile the only thing that needs to be built with 1.4 though?

[mdempsky]

@bradfitz

In any case, the point behind my snark was to make sure that the package does NOT become a "util" package that itself depends on many things the caller of your package may not want.

I was imagining a package that's limited to just providing current standard library functionality, with backwards compatible implementations for bootstrapping under older Go releases. That is, for non-bootstrap builds, the packages don't do anything but pass through calls to the standard library.

It seems like you're suggesting that cmd shouldn't treat std as a single monolithic dependency, but instead should view each standard library package dependency individually. I understand why this is important within std, but it's not clear to me that it extends to cmd too.

[bradfitz]

I understand why this is important within std, but it's not clear to me that it extends to cmd too.

I personally don't care too much. I'm mostly echoing the objections I've heard about "util" packages in the past.

Practically, it matters less here because this is an internal package and we can therefore audit the fixed number of users of the "util" package and verify they're not pulling in anything unnecessary via the util package they wouldn't depend on otherwise via other paths.

[dgryski]

At what point to we bite the bullet and say that you need something newer than 1.4 to build the latest Go release and add an extra step to bootstrapping from C?