News for hackers. Stuff that matters.
Re:Structured Logging with Slog by masklinn on Tuesday August 22, 2023 @02:29PM (#37226750)
> Passing in an optional `map[string]string` or something would be better

It would definitely not be better from the point of view of

> We wanted slog to be fast.

Re:Structured Logging with Slog by packetlost on Tuesday August 22, 2023 @02:33PM (#37226807)
A better interface/API is really what I meant. The performance characteristics are probably worth the tradeoff.
Re:Structured Logging with Slog by returningfory2 on Tuesday August 22, 2023 @02:36PM (#37226849)
Passing in a map would require an extra allocation for the map memory for each log line. I think the performance would probably not be great?
Re:Structured Logging with Slog by packetlost on Tuesday August 22, 2023 @02:41PM (#37226900)
it depends. I believe map literals are stack allocated if they aren't shared across goroutines or globals.
Re:Structured Logging with Slog by masklinn on Wednesday August 23, 2023 @02:48AM (#37232606)
While the hmap struct can be stack allocated if it does not escape, I’m pretty sure the buckets still need to be heap-allocated. I do not believe hmap has a “flat structure” variant which could live entirely on the stack, though I could be wrong.
Re:Structured Logging with Slog by Ferret7446 on Wednesday August 23, 2023 @03:54AM (#37233033)
It's most definitely not. Logging is crucial for monitoring services, and making logging statements many times slower will either sink your service or push developers to avoid logging and making the service impossible to debug.

Most log metadata will be attached by libraries and middleware, so service/application devs won't even see most of it.

Re:Structured Logging with Slog by packetlost on Wednesday August 23, 2023 @11:42AM (#37237781)
I think you interpreted my comment the wrong way, I think the performance tradeoffs are worth the mediocre API design. My bad for making it ambiguous