Hey! Thanks for sharing this experience! Very interesting!
Yes, definitely, I will use Go profiling tools.
El mar, 26 ago 2025 a las 1:54, Kurtis Rader (<kra...@skepticism.us>)
escribió:
> 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.
>
> On Mon, Aug 25, 2025 at 11:39 AM JUAN DIEGO LATORRE RAMIREZ <
> diegolatorre...@gmail.com> wrote:
>
>> 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+unsubscr...@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>
>> .
>>
>
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>
--
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/CAGV9VpRXZgfNRu9qnoCTaO8yLyatDN6z1b00G4x9OAXj7Uu0Dg%40mail.gmail.com.
