Disabled Backtracer performance impact

[Tag365]

Question regarding performance.

We currently create separate logger instances (using multisink with console and file output). for all the different log levels and check the log level on our end before calling logger::log. Now the library will for sure check the log level too, so there are two similar checks, which made me question the performance on our end.

I tested moving to one logger instance/default logger and let the library do everything, however its quite a lot slower.
We use Valgrind Callgrind to profile our code and with the one logger I see spdlog::details::backtracer::enabled appearing.
I would like to keep the runtime level check, rather then compile time using the provided MACRO's.

Therefore the my main question: Is it possible to remove the backtracing completely in compile time rather then just deactivating it?

[gabime]

Are you suggesting that the following code is slow?

SPDLOG_INLINE bool backtracer::enabled() const { return enabled_.load(std::memory_order_relaxed); }

Or did you perhaps enable the backtracer itself? (That would significantly slow down the logger)

[Tag365]

I disabled the backtracer as per docu spdlog::disable_backtrace().
Enabled it was visible that the ring buffer was used, disabling was already performing better.
It's probably not slow for one run, but number of calls still adds up in the end. With atomic on (highly) multi threaded software.

[gabime]

Please provide numbers and way to reproduce them. Otherwise this is just guessing.

[Tag365]

Alright, didnt manage to get my approach in the structure of your benchmark code, but create dummy repo with the two approached that are similar to our current setup.
https://github.com/Tag365/spdlog_bench/tree/master

There is a indeed a performance difference.

[2025-06-30 14:45:57.094] [info] Spdlog elapsed: 0.028735 seconds
[2025-06-30 14:45:57.094] [info] Split loggers elapsed: 0.000004 seconds

I've yet to understand why its so much slower on our end, here it's in sub second range for those millions of debug logs. But in our tests there are minutes between those approaches for similar amount of debug statements. (Of course more spread out at various different times and not all at once) And I tested the compile-time log level for trace and debug while info and above use the default logger and its back to our usual performance, with the debug code in place its 30% slower