[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 #13 from Steven Schveighoffer <schveiguy at 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 :)

--