Disclaimer: I was messing around with slog mostly for my own amusement and none of this comes from an actual need.

What version of Go are you using (go version)?

$ go version go1.21rc4 linux/amd64

Does this issue reproduce with the latest release?

yes, with go1.21rc4

What operating system and processor architecture are you using (go env)?

not relevant

What did you do?

When using TextHandler with slog and setting ReplaceAttr, there's one allocation per log rather than zero.
Note that with JSONHandler, there are 4 allocations reported by this test and I haven't tracked them down.

package alloc_test

import (
	"io"
	"log/slog"
	"testing"
)

func TestAlloc(t *testing.T) {
	pureLogger := slog.New(slog.NewTextHandler(io.Discard, nil))
	replaceLogger := slog.New(slog.NewTextHandler(io.Discard, &slog.HandlerOptions{
		ReplaceAttr: func(groups []string, a slog.Attr) slog.Attr { return a },
	}))
	pureAllocs := testing.AllocsPerRun(1, func() {
		pureLogger.Info("hello")
	})
	replaceAllocs := testing.AllocsPerRun(1, func() {
		replaceLogger.Info("hello")
	})
	if pureAllocs != replaceAllocs {
		t.Fatalf("allocs without ReplaceAttr %.0f != allocs with ReplaceAttr %.0f", pureAllocs, replaceAllocs)
	}
}

What did you expect to see?

Test passing

What did you see instead?

allocs without ReplaceAttr 0 != allocs with ReplaceAttr 1

More context

The difference is that without ReplaceAttr, Level is directly converted to string and with it, it's kept as the Level type so that ReplaceAttr can act on the Level type.

When it comes time to print Level's value, its implementation of MarshalText returns a byte slice, but the conversion from string to byte slice causes an allocation. This is basically a limitation of the TextMarshaler interface. Not that everything we are seeing here applies to any marshaling of slog.Any wrapped values.

I don't think there's a more efficient way to implement MarshalText for Level. I considered two bad alternatives:

• Level.MarshalText can use the unsafe package to create a byte slice from a string without the allocation. The weird thing about this is that it exposes the memory in such a way that if the caller of MarshalText assigns to any of the returned bytes, it causes a segfault. It would be weird for the caller to do that, but risking a segfault is not something we'd want to expose anyone to.
• Level.MarshalText can return pre-allocated global slices for the standard levels. This is also less safe that what happens now, but instead of a segfault, assigning to the returned slice results in log levels being printed incorrectly for future logs.

Proposed solution

Prioritizing Stringer over TextMarshaler would solve this issue. We can put this:

		if st, ok := v.Any().(fmt.Stringer); ok {
			s.appendString(st.String())
			return nil
		}

right here above the TextMarshaler check.

Right now String() is effectively what's called if TextMarshaler is not implemented, but it's called indirectly through fmt.Sprintf("%+v", v.Any()), which causes an allocation. By putting the stringer option first and doing it explicitly, we give all "Any" values an opportunity to marshal themselves efficiently as strings.

A similar trick can be done in appendJSONMarshal for the json case to remove all 4 allocations. I think it wouldn't be completely crazy for slog to prefer to format values as strings regardless of the encoding of the logs. It can be argued that the encoding of the logs shouldn't affect the content of the logs and the preference for using Stringer would make the two implementations more consistent with each other.