Collaboration with Onelog?

[rs]

Collaboration with Onelog?

[rs]

I’m discovering OneLog too. The APIs are not compatible, so I don’t see how we could merge the two projects. It’s fine to have different projects with different ideas. If you prefer a different API, you should use it.

I chose this chaining API for zerolog because it is the only way (I know) to avoid allocations. Passing a lambda should create an allocation for the lambda itself. I’m curious to see how OneLog achieve better performance with this construct. I might steal some ideas ;)

[bruth]

Yes understood. I realize the APIs are different so maybe I was just implying to steal some ideas.. 😄

…

On May 8, 2018, at 1:51 PM, Olivier Poitrey ***@***.***> wrote: I’m discovering OneLog too. The APIs are not compatible, so I don’t see how we could merge the two projects. It’s fine to have different projects with different ideas. If you prefer a different API, you should use it. I chose this chaining API for zerolog because it is the only way (I know) to avoid allocations. Passing a lambda should create an allocation for the lambda itself. I’m curious to see how OneLog achieve better performance with this construct. I might steal some ideas ;) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[rs]

I tried to reproduce the benchmarks with the types supported by both libraries, and I can't reproduce the result shown on onelog's README. Here is the bench I run: https://gist.github.com/rs/988efc55268b7d4df5ffb01a293c4bdc

Perhaps @francoispqt can provide the code of his bench so I can understand what happens. If it is based on zap's benchmark, the current implementation of onelog does not support most of the field types required by the test. If unsupported types were removed, it could explain the difference but the result would be biased.

[francoispqt]

Hi Olivier,

Sorry for late answer, I live in Hong Kong, was sleeping.

Here are the benchmarks: https://github.com/francoispqt/zap/tree/onelog-bench/benchmarks

Onelog does cover all types, but results for zerolog seemed really weird. So after reading your messages in this thread, I inspected Zap's benchmark suite for zerolog. And they don't implement MarshalZerologObject nor MarshalZerologArray interface on their structures or slices (I actually didn't know there was such interfaces in zerolog until I see your gist), and were calling Interface() for these types, which is clearly unfair as Zap does it for his own benchmark and has Strings and Ints methods.

For onelog I implemented the right interfaces, so I did the same for zerolog and used the correct types when logging, you can find it here https://github.com/francoispqt/zap/tree/zerolog-bench/benchmarks.

The results from a single run are giving zerolog more credits:

BenchmarkAddingFields/Zap-8         	 1000000	      1894 ns/op	     770 B/op	       5 allocs/op
BenchmarkAddingFields/francoispqt/onelog-8       	 1000000	      1005 ns/op	     128 B/op	       4 allocs/op
BenchmarkAddingFields/rs/zerolog-8               	 1000000	      1210 ns/op	     129 B/op	       4 allocs/op
BenchmarkAddingFields/rs/zerolog.Check-8         	 1000000	      1218 ns/op	     129 B/op	       4 allocs/op

So apologies @rs for the wrong results presented in onelog's README, I will update it.

Zerolog is an amazing package, best logger out there in terms of performance and usability IMHO. Actually the case where onelog is faster (other than disabled logs) rarely happens in real environment. Still I will try to improve onelog, I'm already working on having a chaining syntax (almost done), adding built in methods and obviously improving the underlying JSON encoder.

[rs]

It’s not your fault, zap refused to merge my fixed benchmark with the right implementation.

I’m fan of gojay. I might use it at some point. If you manage to beat zerolog, please tell me, I’m always interested to learn new tricks :)

[francoispqt]

Glad you like gojay, it's getting closer v1.0.0 soon and I believe there's still room for optimisation.
If you use it I'd be happy to have your feedbacks.

Beating zerolog will be really hard, will try to get closer at least ;)

[bruth]

🙌 I love this conversation. Respect.

[rs]

I started to work on a benchmark tool to ease the benchmarking of log libraries. You can find the code here: https://github.com/rs/logbench. I will automate the running/publication of the results in an easy to read format.

Let's close this issue as the initial request is addressed.

[Globegitter]

It would be quite interesting to include onelog into logbench as well to have a fair comparison between the two.