Add zerolog benchmark, fix go-kit bench and update README #436
Conversation
|
|
|
Tests are broken because of a missing license header in Just putting it out there - why not improve zap to fix any performance gaps instead of having more golang logger fragmentation? I have my own logging lib too github.com/peter-edge/lion-go but I'm moving to put my work towards this. There's probably some issue but just wondering. |
|
Thanks for the heads up, I will fix the header. About making zap faster, I’m afraid it would not be possible without changing the API in a non backward compatible way. Zerolog can be so fast because of its API is not using variadic arguments and because its output format is only JSON so it can incrementally build the JSON even in a single buffer with no intermediary form. Zap is more versatile but it comes at a cost. When you need this flexibility it is a great choice. If all you need is fast JSON logging, you might want to consider zerolog. |
|
I'd say this would be better to merge if there was such a pros/cons list advertised on zerolog, as opposed to the sensationalist headline on https://www.reddit.com/r/golang/comments/6c9k7n/zerolog_is_now_faster_than_zap, but just my two (friendly) cents :) haha |
|
I plead guilty on the clickbait title :) |
There was a problem hiding this comment.
Glad to see that zap has sparked some interest in logging performance! zerolog is an interesting take on the problem. Making zerolog.Context and zerolog.Entry not concurrency-safe certainly opens up some options that we didn't explore here.
From looking at these benchmarks and some of zerolog, I don't think that zap's flexibility is relevant here - both libraries are just wrappers around a byte slice of incrementally-encoded JSON. Neither library is maintaining an "intermediary form," and I'd be quite surprised if the virtual dispatch required by zap's interfaces accounts for the perf difference seen here. (Of course, I've been wrong before.)
Zap's variadic argument support is also a red herring: zerolog actually allocates more frequently than zap.
A small portion of the performance difference comes from zap's automatic inclusion of the calling function's name, but a larger portion appears to come from some overhead introduced by zap's JSON encoder.
I'm going to investigate a bit more here, but I certainly don't mind including zerolog benchmarks. I'll likely push a few changes to this branch before merging, but I'm happy to take this from here.
Thanks for the contribution!
|
Thank you for you feedback @akshayjshah. Can you elaborate on "zerolog actually allocates more frequently"? |
|
As measured by these same benchmarks, zerolog allocates at least as often as zap, and sometimes more often. |
|
The benchmark shows that because one of the field types in the "fake fields" is allocating more on zerolog than on zap. For usual field types, there is no allocation at all in either case. |
|
Yep, I'm aware. I'm just pointing out that the performance difference observed isn't because zerolog is allocating fewer objects on the heap. |
No description provided.