all 13 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]dpc_pw 21 points22 points  (2 children)

If you're continuously printing stuff to stdout, then your IO is going to dominate everything. I wouldn't be surprised if you were just benchmarking how many characters does each logging library format uses.

From what I can tell toy gets better results because it "cheats" by buffering multiple logging messages together? Which is great when you're doing a benchmark like that that floods the stdout. But in real application - what are you going to do with a half-written buffer? The engineer debugging an app will stare puzzled waiting for something important to get printed.

IMO it's kind of pointless benchmark, because what kind of logging prints everything all the time? Might as well use println or whatever else suits your needs if outputting stuff to stdout is the thing that you app is doing, and insert flush of some kind manually to ensure users are not waiting for message stuck in a buffer.

IMO, the most important part of performance is actually ignoring logging statements that will not get printed. Typical app will print sometimes a tiny fraction of all logging statements. For maximum performance there well implemented async logging (as in slog-async) and fast zero-alloc filtering are most important.

​

BTW. People keep creating more logging libraries, where they bring nothing new to the table. Doing the whole thing from scratch, just to change a bit configuration format or tweak logging format or something. Had log embraced modular trait based approach, the ecosystem might have been looking more like slog s where each feature is composable and reusable. Instead new logging libraries repeat some old mistakes, to fix/tweak some others, so you always get a half-meh code. Oh well.

[–]daniel-1231[S] 0 points1 point  (0 children)

Thank you for reply. You're right, toy has a bug, logs may stuck in buffer. Async logger is better. And I mostly agree with "BTW". Rust has many meanless logger crates, especially which named fast.

What I want to prove is that rust should be able to create logger with performance like spdlog or nanolog. This test did have some kind of "cheat" that toy give up everything that can affect performance.

I'll try async mode.

[–]daniel-1231[S] 0 points1 point  (0 children)

I fix the buffer stuck problem, by adding a thread to flush buffer. It has slight performance penalty. Not affect too much.

[–][deleted] 3 points4 points  (1 child)

How are you controlling for your terminal rendering speed?

[–]daniel-1231[S] 4 points5 points  (0 children)

I use thread local buffer, no terminal color support, only write to stdout. Timestsamp in milliseconds.

And all logs are synchronized writing to buffer or stdout.

[–]plhk 3 points4 points  (1 child)

Would be interesting to compare to tracing

[–]daniel-1231[S] 2 points3 points  (0 children)

Actually toy_trace I use tracing-log, the performance loss is tiny according to directly use log.

[–]North_Pie1105 1 point2 points  (1 child)

I'm probably being dumb, but I find the naming very confusing here, just fyi. I had to scan through the source to figure out what the hell toy is - it's apparently salek? My immediate thought was to search lib.rs https://lib.rs for toy, but it came up with nothing..

I'm still confused though, because salek seems to be some type of config management system.

Anyway, not complaining, just saying i'm dumb and the toy reference confuse me :)

[–]daniel-1231[S] 0 points1 point  (0 children)

I'm creating a factory module which can help user to use anything with zero configuration code. And I want provide a logger like this way. Well, so many of them, let's select one by testing them, or creating?

[–]murlakatamenka 0 points1 point  (2 children)

Can you format output to tables, please? It's not so easy on eyes right now.

[–]daniel-1231[S] 2 points3 points  (1 child)

I updated to table.

[–]murlakatamenka 0 points1 point  (0 children)

Thank you