Good point, we never really defined what 'lazy rendering' actually is. Let's say we use
os_log to log
os_log_error(OS_LOG_DEFAULT, "%d %d", 1, 2);
it doesn't actually do the string interpolation when logged. It will just ship the static string
"%d %d" and the
1 and the
2 as binary data to the logging system. The string interpolation is done when you actually look at the message using the
log utility or
Console.app or similar. That's really quite cool because you shift some of the costs from producer of log messages to the consumer. On the server however there are lots of standard solutions which expect textual/structural output in a certain format so there's not necessarily that much value in it. Again, very happy to change my mind if there's evidence that it will help.
@Joe_Groff was is something like this:
[app thread 1] \ \ [app thread 2] +===logging firehose (1)===> [logger daemon thread] ==(2)==> logging mechanism (ie. file/db/stdout/...) / [app thread 3] /
where we have essentially two pipes, the logging firehose (1) and then a rendering stage (2). I think Joe was suggesting to support lazy rendering in (1) but not in (2). That way we could shift the rendering overhead from log message producers (app thread N) to the logger daemon thread. The benefit would be that in case the logging mechanism supports lazy rendering we could just forward it.