Performance

You don't pay for disabled log levels

If you have 'levels="off"' in your config, you don't get any visible effect from log statements. During our internal testing we never got any benchmark results > 1 microsecond (Time measured in nanoseconds):

What affects performance

• Length of log message and arguments list
• Dispatcher configuration
• Format
• Logger type (Sync/Async)

Performance recommendations

There are several simple recommendations, that almost gives you a guarantee that log operations won't noticeably affect your business logic performance in production. So, when you are running in production:

• Don't use 'Info' (and above) messages in performance critical operations that are frequently called. Check Log levels wiki page.
• Don't allow log levels below 'Info' both in global constraints AND in exceptions.
• Avoid special calculations that are done just to log something. For example: log.Debug("Result=%d", calculateResult()) would of course call 'calculateResults() every time, even if Debug is totally disabled. If you really need that, use a closure: log.Debug(func() string { calculateResults() })
• Don't use too many exceptions. So it is always better to pass references to something already calculated in your log arguments lists.
• Don't use heavy formats. For example, "%Date/%Time" verbs are really heavy in terms of logging. So use "%Ns" instead. Sealog uses a pretty fast log format by default, so if you don't change it, it's okay in terms of performance.
• Use asynchronous behavior (Async timer has a minimal effect on performance)
• Never use concatenation. Use 'log.Debug("var1=%s",var1)' instead of 'log.Debug("var1=" + var1)'.

These rules are for production. In development, you can use heavy formats to make log more readable (but more laggy) and do other things that would help debugging if performance is not so critical during development.