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

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

--

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

--- Comment #12 from Jonathan M Davis <jmdavisProg@gmx.com> ---
As I said, I'm not against adding it. It just seems to me that in most cases where you'd be getting the time that quickly, it wouldn't make sense to only have a resolution of 1 ms. And even if it's being filtered, I would think that it would usually be rather ridiculous to be logging stuff hundreds of thousands of times a second and that the number of logging statements should be seriously reduced in such code, so I really think that that's a pretty crazy use case. But I'll add the ability to use the coarse clock instead and let folks shoot themselves in the foot with it if they really want to. Given that it was added to both Linux and FreeBSD's APIs, presumably there are at least some folks who think that it's worth having, even if I think that it's kind of crazy.

--

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

--- Comment #13 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to Jonathan M Davis from comment #12)
> As I said, I'm not against adding it. It just seems to me that in most cases where you'd be getting the time that quickly, it wouldn't make sense to only have a resolution of 1 ms.

Precision vs. speed of retrieval is a reasonable tradeoff which I find quite natural. Think of a printer's fast draft vs. best quality -- I can think of reasons where you would want both. The most obvious application is logging: you want logging to be very very light CPU time-wise, and the time of the log doesn't have to be generally precise (but it should be accurate). In fact, a log can do without time outputs if necessary -- the most important aspect is the order of the log. The time between two log messages is really a secondary concern.

I think it should be added as an option.

In regards to Windows or Mac options, I think it's OK to just return the same thing as a normal call at this point until we can find another possibility. The optional parameter can mean "use fastest retrieval mechanism even if it's less precise" which would be true if there's only one mechanism :)

--

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

--- Comment #14 from github-bugzilla@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/druntime

https://github.com/D-Programming-Language/druntime/commit/8e29e0621b074a8d368b4d7d344281adb7a91e54 Add ClockType enum to core.time for issue# 13433.

This adds an enum for indicating which type of clock to use when it's appropriate for a time function to have multiple options for the source clock. In the case of MonoTime, to make that work cleanly, the implementation of MonoTime has become MonoTimeImpl, templated on ClockType, and MonoTime has become an alias to MonoTimeImpl!(ClockType.normal). In the case of SysTime (in a separate PR), that will a default template argument to Clock.currTime and SysTime will be unaffected (because in MonoTime's case, the clock that it came from is integral to the type, whereas in SysTime's case, it doesn't matter after the SysTime has been initialized).

https://github.com/D-Programming-Language/druntime/commit/bcfc36b3ca5a229c751c972c607fee57d4febcb2 Merge pull request #990 from jmdavis/13433

Add ClockType enum to core.time for issue# 13433.

--

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

--- Comment #15 from Sobirari Muhomori <dfj1esp02@sneakemail.com> ---
BTW, Windows 8 has GetSystemTimePreciseAsFileTime function for time reading with better precision.

--

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

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #16 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to Sobirari Muhomori from comment #15)
> BTW, Windows 8 has GetSystemTimePreciseAsFileTime function for time reading with better precision.

If there's a way to utilize this and still be binary compatible with Win XP, that might be possible. But we can't require Windows 8 for D.

And actually, this has been pulled, so I think we can close this.

--

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

--- Comment #17 from Sobirari Muhomori <dfj1esp02@sneakemail.com> ---
(In reply to Steven Schveighoffer from comment #16)
> But we can't require Windows 8 for D.

How about server platforms? Those are less conservative than desktop.

--

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

--- Comment #18 from Vladimir Panteleev <thecybershadow@gmail.com> ---
(In reply to Sobirari Muhomori from comment #17)
> How about server platforms? Those are less conservative than desktop.

So we release two Windows DMD builds, one for client version of Windows and one for server versions? With the caveat that the binaries they produce might not be inter-compatible? Makes no sense.

The function can just be loaded dynamically. This is already done in Phobos in a few places (grep for GetProcAddress).

--

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

--- Comment #19 from Sobirari Muhomori <dfj1esp02@sneakemail.com> ---
(In reply to Vladimir Panteleev from comment #18)
> Makes no sense.

Already done: 64-bit executables are incompatible with 32-bit systems. I think, it fits D ideology "good by default, closer to the system if requested". Well, I agree, dynamic loading is already good enough.

--

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

--- Comment #20 from Vladimir Panteleev <thecybershadow@gmail.com> ---
(In reply to Sobirari Muhomori from comment #19)
> Already done: 64-bit executables are incompatible with 32-bit systems.

Except that:
- We do not actually release separate 32-bit and 64-bit versions
- 64-bit Windows versions go as early as Windows XP
- The API in question is available equally on 32 and 64 bit editions of Windows
- The pointer size has nothing to do with the OS edition or version.

Like I said, makes no sense.

--