Clarification on core:log stripping vs runtime overhead in release builds

Explain
1

Hey everyone I am new to the Odin language and I really like it so far! I’m trying to understand the precise behavior of log.debugf in a release build (-o:speed).
Specifically:

  1. If I have a line like log.debugf("Value: %v", get_expensive_data()), and at runtime my context.logger is either nil or set to .Error level, is the call to get_expensive_data() still executed?
  2. Does the compiler physically strip the log.debugf calls and their associated format strings from the binary, or are they kept in the executable and simply ‘silenced’ by a runtime check of the context’s log level?
  3. If I want to ensure zero runtime overhead and zero string bloat for debug logs in my final binary, is a wrapper using @(disabled=...) the recommended way, or does the compiler/core library have an automatic way to handle this?"
2

1/2. Yes, get_expensive_data still gets called. log.debug isn’t actually @(disabled), so the proc does still exist and still gets called, so its arguments need to be evaluated. The “debug”-ness is just the log level it gets logged at, which will get silenced by a run-time check.
3. Procs that are @(disabled) (and the condition is met) actually get removed, including evaluation of their arguments (i.e. get_expensive_data wouldn’t get called if log.debug were @(disabled)).

3

Is there a reason why log.debug isnt @(disabled) by default when not running in debug mode?

4

Because log.debug is not related to ODIN_DEBUG, rather it’s the level on the logger itself. package runtime - pkg.odin-lang.org e.g. Logger_Level.Debug.

1 Like