I'm not familiar with the compiler and the fmt package enough to say whether this should or could be fixed. But my undesrtanding is that in general you should not use fmt in hot paths where an allocation or interface{} work is not acceptable.

This is #8618 I believe.

This is not related to interface. Following code doesn't make the input arguments escape.

package main

func f(a interface{}){
	switch a.(type) {
	case int:
		println("int")
	case []int:
		println("[]int")
	case *int:
		println("*int")
	case *[]int:
		println("*[]int")
	}
}

func main() {
	var x = []int{0, 1, 2}
	
	f(x)
	f(x[0])
	f(&x)
	f(&x[0])
}

@mvdan, I use log package quite often. The log package warps the fmt functions. So I hope the fix is good to optimize log functions.

But if there are many different strings needed to be passed to the fmt.Print functions in a goroutine, maybe it is not bad to allocate them on heap, to avoid stack growing and shinking.

I'm just surprised to see that the performance of log is cause of concern. Or is this just out of curiosity?

I'll keep this open as a long-term meta bug about escape analysis, but small examples are generally more actionable.

Analyzing fmt routines to know that the arguments don't escape is hard. The callgraph is

 Println
 Fprintln
 doPrintln
 printArg
 handleMethods

handleMethods will call the Format, GoString, String, or Error methods on the passed-in type. Escape analysis doesn't know what those functions will do, so their arguments escape. That escape propagates all the way up to Println.

package main

import "fmt"

type A []int

var sink A

func (a A) String() string {
	sink = a
	return "foo"
}
func main() {
	a := []int{}
	fmt.Println(A(a))
}

a escapes!

The only way I see to fix this is to have type-dependent escape analysis. I don't see that happening any time soon.

fmt.Sprint() was being cited as the "final litmus test" for escape analysis by @dvyukov in his document:
https://docs.google.com/document/d/1CxgUBPlx9iJzkz9JWkb6tIpTe5q32QDmz8l0BouG0Cw/preview

@mvdan

I'm just surprised to see that the performance of log is cause of concern.

yes, sometimes, it is.

Another bad side effect is these functions change what it measure when it participate.
For example, I want to check how much memory is allocated on stacks and heap, but the results of the fmt functions affect the query results.

@mvdan

I'm just surprised to see that the performance of log is cause of concern.

yes, sometimes, it is.

Another bad side effect is these functions change what they measure when they participate.
For example, I want to check how much memory is allocated on stacks and heap, but print some values by calling the fmt functions will affects the query results.

Is it easier to write something like //go:escapesArgToHeap , then put it before the function body?
When you know that something can be escapes heap, I think you can just tell the compiler to do that with import "unsafe" package.

I am pretty sure this is a dup of #8618. The counterexample listed above is all in one package, which is a much easier problem. #8618 requires escape analysis across a package boundary.

Yes, I confirm duplicate of #8618.