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

[JUAN DIEGO LATORRE RAMIREZ]

Hey guys, I'm configuring the logger in my app, so I have this interface:

// 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?   

[Alexander Ertli]

Hey,

Don't think there is any mentionable overhead in doing that. 
___
// WithAttrs returns a new [TextHandler] whose attributes consists
// of h's attributes followed by attrs.
func (h *TextHandler) WithAttrs(attrs []Attr) Handler {
return &TextHandler{commonHandler: h.commonHandler.withAttrs(attrs)}
}
____
It creates a new handler object (shallow copies) but so do also many other methods. 

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/7e10c173-3a2c-4d1f-a0ce-cd6de3d4f2dfn%40googlegroups.com.

[Jason E. Aten]

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://pkg.go.dev/runtime/pprof

https://go.dev/blog/pprof

https://medium.com/@jhathnagoda/go-profiling-with-pprof-a-step-by-step-guide-a62323915cb0

https://www.slingacademy.com/article/profiling-go-applications-with-pprof/

https://support.tools/golang-pprof-profiling-guide/

[Amnon]

It allocates, even if the resulting logger never produces any output.
So, yes it can be an issue.
So I generally create loggers with a long lifespan, but avoid creating loggers with short lifespans
(e.g. in order to declutter my log statements).
As Jason suggested, profiling, is your friend.
Grabbing an allocation profile from your service running in production will tell you to what extent this is a problem.

[Kurtis Rader]

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.

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/7e10c173-3a2c-4d1f-a0ce-cd6de3d4f2dfn%40googlegroups.com.

--

Kurtis Rader

Caretaker of the exceptional canines Junior and Hank

[JUAN DIEGO LATORRE RAMIREZ]

Hey! Thanks for sharing this experience! Very interesting! 

Yes, definitely, I will use Go profiling tools.