[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13433

--- Comment #11 from Kevin L <kevin.lamonte at 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.

--