Comment 1:

Status changed to Accepted.

Comment 2:

Labels changed: added repo-main.

This thread explains how this issue causes 2 allocs on every call to os.(*File).Write.
https://groups.google.com/forum/#!topic/golang-nuts/0hfeLJP1LSk

Dmitry started this in CL 3503. Note that this requires improved escape analysis.

CL https://golang.org/cl/35554 mentions this issue.

For the reference until this is fixed some of us use ad-hoc printf-style mini language to do text formatting in hot codepaths without allocations. For example if in fmt speak you have

s := fmt.Sprintf("hello %d %s %x", 1, "world", []byte("data"))

the analog would be

buf := xfmt.Buffer{}
buf .S("hello ") .D(1) .C(' ') .S("world") .C(' ') .Xb([]byte("data"))
s := buf.Bytes()

It is a bit uglier but runs faster and without allocations:

pkg: lab.nexedi.com/kirr/go123/xfmt
BenchmarkFmt-4       5000000           246 ns/op          72 B/op      3 allocs/op
BenchmarkXFmt-4     20000000            57.9 ns/op         0 B/op      0 allocs/op

Details:

https://lab.nexedi.com/kirr/go123/commit/1aa677c8
https://lab.nexedi.com/kirr/go123/blob/c0bbd06e/xfmt/fmt.go

Note that when the arguments are constants, they no longer allocate on tip, so this is a bit better than it was.

@josharian thanks for feedback. For the reference the above benchmark was for tip (go version devel +d728be70f4 Thu Apr 20 01:37:08 2017 +0000 linux/amd64).

What are the status about this issue ? Is anyone working on ?

@bnjjj I'm not aware of anybody actively working on this.

One data point here. The gio authors are considering an API design choice: whether to use an interface type or a function type. Using the interface type results in nicer code (when there's a literal struct, it can be used directly rather than via a method expression to obtain the function value), but results in allocations, and avoiding allocations is a key consideration in that context.

To illustrate with a couple of small examples:

This program, using a function type, does not incur any allocations. The required closures can all be allocated on the stack. https://play.golang.org/p/FC4taLlhVGz

This equivalent program, using an interface type, incurs an allocation for each interface conversion. https://play.golang.org/p/XPfcNSMPt82

Given that interfaces are often more idiomatic than function types in Go, it would be nice if they could be used interchangeably without a significant performance difference.

As of five years ago(!), this needed escape analysis improvements. Those stalled; see CL 3503. Maybe @mdempsky could weigh in.

FWIW, I was curious what the current gap is for avoiding allocations with the fmt print function arguments.

As far as I could see, it looks like as of Go 1.21, there are ~6 reasons val escapes here:

 val := 1000
 fmt.Sprintf("%d", val)

I did an exploratory pass on some possible solutions a couple of months ago, which I recently sent as stack of CLs.

Some of the CLs are likely wrong, but part of my hope is that sometimes if someone helps sketch the contours of a problem, then frequently other people are better able to jump in with solutions or their own explorations (whether those "other people" are experts, or just other people who are curious).

Brief summary of the ~6 reasons:

1. The fmt print methods store the user interface arguments on a pp struct. The pp struct escapes, and the heap can't point to the stack, so the user arguments escape as well. (Sent CL 524938).

2. reflect.Value.Pointer also causes escapes. (Sent CL 524939).

3. reflect.Value.Slice also causes escapes. (Sent CL 524940).

4. Interface conversions and interface methods call like arg.String() in handleMethods also cause the user arguments to escape. This might be the most fundamental reason. (Sent CL 524945 and some related CLs. Matthew Dempsky then said he liked the core idea and he sent an alternative implementation in CL 526520. I also opened #62653 to help discussion on this specific piece).

5. Within reflect, packEface causes reflect.Value.Interface to escape, which causes the fmt args to escape. (Sent CL 528535).

6. Also within reflect, method values cause conditional allocation of a methodValue struct, which also causes the fmt args to escape. (Sent CLs 528536, 528537, and 528538. These CLs might be the ugliest).

   • UPDATE: creating a new type of pragma was indeed too ugly, so I abandoned those three CLs and instead sent a hopefully better approach spread across CLs 530095 (runtime), 530096 (compiler), and 530097 (reflect).

By the end of my first-cut stack (as of CL 528538), arguments to Sprintf like the Point struct here no longer get heap allocated:

  type Point struct {x, y int}
  p := Point{1, 2}
  fmt.Sprintf("%v", p)

Some of those CLs are more-or-less shots in the dark, but I tried to put some context in the CL descriptions and elsewhere in the hopes of other gophers jumping in with alternative solutions (or suggestions for corner cases to test, or questions, or ideas for improvement and so on...).

The CLs all pass all.bash and pass the older TryBots (but hit some LUCI-specific issues with the new TryBots).

If you are new to the escape analysis code:

• The best place to start is probably Matthew Dempsky's nice introduction in escape.go.
• I tried to add some additional general explanation of how escape analysis currently works, including via some examples here and at the start of here.
• For the interface method challenges, I tried to give some narrative examples here with the results reflecting the new behavior. Also, the CL 524945 commit message attempts to explain how escape analysis arrives at its result for interface method calls in Go 1.21 and earlier. (Definitely room for improvement in those explanations 😅).

Change https://go.dev/cl/524938 mentions this issue: fmt: avoid storing input arguments on pp to help escape analysis

Change https://go.dev/cl/528535 mentions this issue: reflect: leak packEface input to result rather than heap

Change https://go.dev/cl/530095 mentions this issue: runtime: manually represent reflect.methodValue in stack map for methodValueCall assembly

Change https://go.dev/cl/530096 mentions this issue: cmd/compile/internal/escape: recognize more self-assignment patterns

Change https://go.dev/cl/530097 mentions this issue: reflect: avoid always escaping in Value.Interface

Change https://go.dev/cl/524944 mentions this issue: cmd/compile/internal/escape: reserve space in leaks encoding for interface receiver data

Change https://go.dev/cl/524945 mentions this issue: cmd/compile/internal/escape: analyze receivers in interface method calls

Change https://go.dev/cl/528539 mentions this issue: cmd/compile/internal/escape: propagate method usage for analyzing receivers in interface method calls

Change https://go.dev/cl/524937 mentions this issue: cmd/compile/internal/escape: make escape analysis -m=2 logs more accessible