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.

On Monday, 25 August 2025 at 22:08:28 UTC+1 Jason E. Aten wrote:

> 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 <
>> diegola...@gmail.com>:
>>
>>> 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 golang-nuts...@googlegroups.com.
>>> 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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/golang-nuts/6ab2ea92-a832-4e32-9a29-37b2d267723an%40googlegroups.com.

Reply via email to