Efficient Logging for Disabled Statements in Go

In critical paths, it's beneficial to embed debug/trace logging statements that can be toggled dynamically at runtime. This practice is ideal for debugging production systems taken offline or test systems mirroring the production environment.

However, there's a crucial requirement for this type of logging: disabled statements must have minimal performance impact. In C/C , this was achieved through a LOG macro that suppressed argument evaluation until a flag was checked.

Implementing Disabled Logging in Go

Emulating this behavior in Go presents challenges. Using io.Discard with log.Logger isn't an option as it formats log messages even when disabled.

An initial attempt with an EnabledLogger struct implements the log.Logger interface, enabling/disabling logging based on the Enabled flag. However, argument evaluation remains unsuppressed, potentially leading to performance issues for arbitrary function calls.

Two Workarounds

To address this, there are two workarounds:

1. Wrapper Types: Utilize wrapper types to defer function calls, ensuring that expressions aren't evaluated until the enabled check is passed.
2. Manual Checks: Manually wrap the logging statement with an enabled check to prevent execution if disabled.

Both approaches result in verbose and error-prone code, opening the door to potential performance regressions.

Other Options

Despite Go's static evaluation rules, there are some additional options:

• Custom Log Formatters: Leveraging the fmt.Stringer and fmt.GoStringer interfaces can delay argument formatting until execution time.
• Runtime Logger Swapping: The entire logging mechanism can be swapped out via a logger interface or build constraints.
• Go Code Generation: Advanced code generation techniques can potentially preprocess code by parsing the AST and generating specialized debug builds.

While these solutions aren't ideal for dynamic runtime configuration, they can introduce performance improvements in specific scenarios.