• via Digitalmars-d-bugs (27/27) Sep 06 2014 https://issues.dlang.org/show_bug.cgi?id=13433

via Digitalmars-d-bugs <digitalmars-d-bugs puremagic.com> writes:

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

          Issue ID: 13433
           Summary: Request: Clock.currTime option to use
                    CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
           Product: D
           Version: unspecified
          Hardware: x86
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: Phobos
          Assignee: nobody puremagic.com
          Reporter: kevin.lamonte gmail.com

While performance-testing the std.logger proposal I stumbled upon
Clock.currTime() as a very significant bottleneck.  Using a modified version of
currTime() to use CLOCK_REALTIME_COARSE instead of CLOCK_REALTIME reduced the
time spent in the overall function by 91% (from 100,000 messages/sec discarded
to 1,100,000 messages/sec).  Similar results have been posted for FreeBSD's
CLOCK_REALTIME_FAST.

I would like to see a way to get Clock.currTime to use
CLOCK_REALTIME_COARSE/FAST.  It could be as simple as "SysTime currTime(bool
fastAndLoose = false)", or another overload.  The documentation would have to
note that "fastAndLoose" time might go backward, or increment oddly.

TickDuration.currSystemTick() could do the same thing using
CLOCK_MONOTONIC_COARSE / CLOCK_MONOTONIC_FAST.

--