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/ On Monday, August 25, 2025 at 9:40:50 PM UTC+1 Alexander Ertli wrote: > 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. > > Am Mo., 25. Aug. 2025 um 20:39 Uhr schrieb JUAN DIEGO LATORRE RAMIREZ < > [email protected]>: > >> 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? >> >> -- >> 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 [email protected]. >> To view this discussion visit >> https://groups.google.com/d/msgid/golang-nuts/7e10c173-3a2c-4d1f-a0ce-cd6de3d4f2dfn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/7e10c173-3a2c-4d1f-a0ce-cd6de3d4f2dfn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/c2e91a44-11f1-41a0-bbb0-920cf053e7d8n%40googlegroups.com.
