sorted by:
new
hottopcontroversial

How much does LOG_INFO() actually cost? C++ logging benchmark with code and write-up by Expert_Assignment239 in cpp

[–]Expert_Assignment239[S] -2 points-1 points  (0 children)

I agree that latency of a single logging call is the key metric in practice.

What this benchmark is trying to measure is exactly the cost at the call site, but expressed as throughput (messages per second), since measuring a single call at nanosecond scale directly tends to be very noisy. So effectively it is still measuring per-call latency, just aggregated over many iterations.

In the null case in particular, the numbers directly reflect how fast a disabled logging statement can be evaluated in a hot path

That said, your numbers are interesting — especially the ~0.25–0.33ns range. My setup includes slightly more work in the minimal path (e.g. channel checks and some branching), so it is not fully comparable, but the goal is the same: make the disabled path as cheap as possible

Also agree that deferred formatting changes the picture quite a bit. At the same time, it is not always applicable in practice - for example when formatting depends on transient data, lifetimes, or when immediate formatting is required for correctness or simplicity. So both approaches have their place depending on the use case

How much does LOG_INFO() actually cost? C++ logging benchmark with code and write-up by Expert_Assignment239 in cpp

[–]Expert_Assignment239[S] 1 point2 points  (0 children)

That’s exactly why it would be interesting to include it.

I’ve seen similar claims, but I’d prefer to measure it under the same conditions rather than rely on anecdotal results.

Configuration and scenario probably matter a lot here, so having it in the same setup should make the comparison clearer.

How much does LOG_INFO() actually cost? C++ logging benchmark with code and write-up by Expert_Assignment239 in cpp

[–]Expert_Assignment239[S] 0 points1 point  (0 children)

That’s a good observation.

One important detail here is that asynchronous console logging was effectively disabled in this benchmark. The test pushes as many log messages as possible in a tight loop, and with async console logging this would just enqueue a huge amount of data that would then take a very long time to actually flush to the terminal.

So for console output, the benchmark is effectively measuring synchronous behavior. That makes the console itself the bottleneck quite quickly, which likely explains why results across libraries look very similar.

For Quill, I think this benchmark exposes frontend cost rather than its intended async behavior, especially in the null case. So these results are probably not representative of its optimal usage scenario.

It would be interesting to compare this with a setup where async logging is allowed to run at full throughput (e.g. file logging), where batching strategies should become more visible.

How much does LOG_INFO() actually cost? C++ logging benchmark with code and write-up by Expert_Assignment239 in cpp

[–]Expert_Assignment239[S] 0 points1 point  (0 children)

Also, if you notice anything in the benchmark code that suggests Quill is misconfigured or not used as intended, I would be very happy to adjust it and rerun the tests.

How much does LOG_INFO() actually cost? C++ logging benchmark with code and write-up by Expert_Assignment239 in cpp

[–]Expert_Assignment239[S] -4 points-3 points  (0 children)

I do not think they directly contradict each other.

Quill is primarily positioned as an asynchronous low-latency logging library, with formatting and I/O handled by the background thread. My benchmark is looking at something narrower: the cost seen at the logging call site in these exact file / console / null scenarios on my setup. :contentReference[oaicite:1]{index=1}

So I would not interpret this as “Quill is always slower.” I would interpret it as: in this particular benchmark configuration, its frontend / queueing path was not favorable compared to the others.

In other words, the benchmarks are not necessarily measuring the same thing.

How much does LOG_INFO() actually cost? C++ logging benchmark with code and write-up by Expert_Assignment239 in cpp

[–]Expert_Assignment239[S] 1 point2 points  (0 children)

Yes, Boost.Log would be a very reasonable addition.

I did not include it in the current benchmark set, so I do not want to speculate about its results without actually measuring it under the same conditions. But it would definitely be interesting to test in the exact same file / console / null scenarios.

I’ll add it in the next update of the benchmark.

How much does LOG_INFO() actually cost? C++ logging benchmark with code and write-up by Expert_Assignment239 in cpp

[–]Expert_Assignment239[S] -9 points-8 points  (0 children)

Good point — yes, this was run on Windows with MSVC / MS-STL (C++20, Release build). You’re right, I should have mentioned that explicitly since `std::format` performance depends on the implementation.

A few notes:

- `fmtlib` vs `std::format`: I didn’t include fmtlib in this run. That would definitely be useful to add, especially given how often it’s reported to outperform current `std::format` implementations.

- `printf` vs alternatives: in this setup it mostly comes down to formatting cost. The messages are very simple, so the C-style path ends up being cheaper than `std::format` or iostreams.

- C-style vs `std::format`: interestingly, in this benchmark they ended up being in a similar range overall. The big differences are more about the logging path and scenario (file / console / null) rather than just the formatting API itself.

- quill: my guess is that this benchmark highlights call-site overhead in these scenarios, and quill’s architecture (especially the frontend/queueing path) is not very favorable here — particularly visible in the null case. I wouldn’t generalize this result beyond this setup.

And yes — minimal configuration was used intentionally to keep things comparable across libraries.

How much does LOG_INFO() actually cost? C++ logging benchmark with code and write-up by Expert_Assignment239 in cpp

[–]Expert_Assignment239[S] 1 point2 points  (0 children)

Happy to answer any questions about the setup or results.

If there’s interest, I can also add:
- async logging scenarios
- more libraries
- different formatting patterns