https://issues.dlang.org/show_bug.cgi?id=13433
--- Comment #11 from Kevin L <kevin.lamo...@gmail.com> --- std.logger's current design doesn't permit Logger subclasses to avoid the call to Clock.currTime() before they get control of the output at Logger.beginLogMsg()/writeMsgPart()/finishLogMsg()/writeLogMsg(). It also doesn't provide any method to filter except via "Logger.logLevel >= something". Together these mean in practice that filtering on anything other that logLevel cannot be performed very quickly. Here are some use cases where a std.logger client might send millions of log calls/sec into Logger.writeLogMsg(), but the Logger implementation emits only a little output: * Filtering on LogEntry.msg text itself, i.e. "only show messages that match this regex". This is equivalent to Log4j/Log4perl/Log4D StringMatch filter. * Filtering on an exact log level rather than at "equal or greater to" log level. This is equivalent to Log4j/Log4perl/Log4D LevelMatch filter. * Filtering on a restricted range of log levels rather than all at "equal or greater to" log level. This is equivalent to Log4j/Log4perl/Log4D LevelRange filter. * Filtering on a Thread/Tid/etc. * Writing all messages to a memory buffer, but only emitting the last X when an ERROR level message comes in. This is equivalent to Log4perl/Log4D BufferAppender. * Any kind of dynamic filtering such as, "when you see _this_ kind of message, start logging a bunch of stuff until you see _that_ kind of message". These could be addressed solely in the std.logger API, but we could also get 90% time gain here. As the submitter, obviously I have a bit of bias already. But the other use cases that led to CLOCK_REALTIME_COARSE/CLOCK_REALTIME_FINE are still out there, e.g. the V8 codec uses it when it is <1ms resolution. --