Is calling With in slog for every log entry a performance issue?

// package types
type Logger interface {
    Debug(msg string, args ...any)
    Info(msg string, args ...any)
    Warn(msg string, args ...any)
    Error(msg string, args ...any)

    // With returns a Logger that includes the given attributes
    // in each output operation. Arguments are converted to
    // attributes as if by [Logger.Log].
    With(args ...any) Logger

    // Operational returns a Logger that includes the given operational log information
    // with the key "operationalLogInfo" and sets the key "operationalLog" to true
    // in each output operation.
    Operational(operationalLogInfo string) Logger
}

And I am using the slog package for the implementation. In the case of Operational, I defined it because very often I have to log with these 2 keys, "operationalLog" and "operationalLogInfo", therefore I want to expose an API for these types of logs. This is the implementation:

type SlogLogger struct {
    logger *slog.Logger
}
// ...
func (l *SlogLogger) Info(msg string, args ...any) {
l.logger.Info (msg, args...)
}
// ...
func (l *SlogLogger) Operational(operationalLogInfo string) types.Logger {
    return l.With("operationalLog", true, "operationalLogInfo", operationalLogInfo)
}

and I use that like this: h.logger.Operational("some message").Info("handling transfer info...")

My question is if the Operational method is efficient? I mean, I have to do a lot of operational logs, and each time I call l.With... is it a significant overhead?

We can't profile your program for you, so how can we know? Depends

on your use, and "significant" is relative to what else you are doing.

Fortunately, the pprof profiler ships with Go, and is pretty easy to use.

https://go.dev/blog/pprof

I can't speak to your specific situation. But a decade ago when I worked in Google's datacenter automation team I inherited an app that made logging calls in Python in a similar manner. During the decommissioning of a datacenter cluster of computers that app became unreasonably slow. To the point it was the bottleneck in decommissioning the cluster rather than the humans doing the physical work. It took me a couple of hours (without the benefit of Go's pprof capabilities) to identify the offending logging calls as the cause of the poor performance. So, as others have pointed out, take advantage of the available profiling tools to determine if your logging code is a significant source of overhead.

Hey! Thanks for sharing this experience! Very interesting!