Cycles are cycles. And when you have a million connections being handled by your application, those cycles add up. I’ve seen the same thing with C/C++ code bases, including ones where methods that were slow were improved by conditionally compiling out logging output that was disabled at runtime with configuration.

The fact that you can reclaim those cycles by compiling the calls right out does not equal “calls to Logger are horribly slow”. I honestly don’t know how slow they are (I don’t have numbers on that), but you could always take Benchee and wrap it around a large number of Logger calls which do not hit the backend and find out.

As for the cost of native calls: they are quite cheap: Latency of Native Functions for Erlang and Elixir · potatosalad

For note, there’s a reason every language with high-performance logging libraries has ‘some’ way to remove logging calls entirely if the language allows for it as even a simple global boolean check can have too high of an overhead in high-performance applications. Plus on the BEAM it’s not like it’s hard to add even brand-new logging statements to a running system, hot-swapping is easy.

I’m pretty sure that was a new feature of 1.7. if you look at the docs for 1.6 here Logger – Logger v1.6.0, you’ll find: " The Logger macros also accept messages as strings, but keep in mind that strings are always evaluated regardless of log-level. As such, it is recommended to use a function whenever the message is expensive to compute." As stated by @NobbZ