Go allocation probe

> The biggest problem is any string you pass as an argument to the fmt functions is moved onto the heap

FWIW, that's not quite correct. For example, a string literal passed as a fmt argument won't be moved to the heap.

The upcoming Go 1.25 release has some related improvements that help strings in more cases. See for example https://go.dev/cl/649079.

> because interface{} is always counted as escaped from the stack

Not quite - if the function accepting interface{} can be inlined (and other heuristics are groovy), then it won't escape.

Trivial example but it applies to real-world programs:

    > cat main.go
    package main
    
    import "github.com/google/uuid"
    
    func main() {
            _ = foo(uuid.NewString())
    }
    
    func foo(s any) string {
            switch s := s.(type) {
            case string:
                    _ = "foo:" + s
            }
            return ""
    }
    
    # Build with escape analysis
    > go build -gcflags="-m=2" main.go
    # command-line-arguments
    ./main.go:9:6: can inline foo with cost 13 as: func(any) string { switch statement; return "" }
    ./main.go:5:6: can inline main with cost 77 as: func() { _ = foo(uuid.NewString()) }
    ./main.go:6:9: inlining call to foo
    ./main.go:6:24: uuid.NewString() does not escape
    ./main.go:6:9: "foo:" + s does not escape
    ./main.go:9:10: s does not escape
    ./main.go:12:14: "foo:" + s does not escape

Not sure if there is already quorum on what a solution for adding labels to non-point-in-time[^1] profiles like the heap profile without leaking looks like: https://go.dev/issue/23458.

[^1]: As opposed to profile that collect data only when activated, like the CPU profile. The heap profile is active from the beginning if `MemProfileRate` is set.

I'm guessing you're using unlurker to post this comment? By any chance, is the comment AI generated? (The use of the term the author is a hint). Apologies if not

The ... is the useful part. We actually want that string, so we can't avoid allocating it.

But the &str at the end is an additional heap allocation and causes an additional pointer hop when using the string. The only reason the function returns a pointer to a string in the first place is so that the nil check at the beginning can return nil. The calling code always checks if the result is nil and then immediately dereferences the string pointer. A better interface would be to panic if the argument is nil, or if that's too scary then:

    func (thing *Thing) String() (string, bool) {
        if thing == nil {
            return "", false
        }
        str := ...
        return str, true
    }