www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 11989] New: Introduce a new monotonic clock type and phase out TickDuration

reply d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11989

           Summary: Introduce a new monotonic clock type and phase out
                    TickDuration
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: druntime
        AssignedTo: nobody puremagic.com
        ReportedBy: jmdavisProg gmx.com



PST ---
Having both TickDuration and Duration is too confusing, and TickDuration does
not follow the conventions of the rest of core.time and std.datetime (since it
predates them), making things even more confusing.

We're currently trying to use TickDuration both to represent the monotonic time
(by getting a TickDuration for the number of ticks since the app started) and
for general durations in system ticks. I posit that it's almost always useless
as a duration in ticks, because Duration is already plenty precise, and if we
have a monotonic time type, then we can get the monotonic system time for high
performance timing, which is really the main reason why you'd currently use
TickDuration rather than Duration. As such, I propose that we introduce a new
type for holding the monotonic time, but which doesn't have any properties on
it which relate to wall clock time (since monotonic time only relates to wall
clock time when you subtract one monotonic time from another to get the elapsed
time between them). The only way to get any kind of wall clock time from them
would then be to subtract them.

So, we'd end up with something like

    MonoTime before = MonoTime.currTime;
    //do stuff
    MonoTime after = MonoTime.currTime;
    Duration timeElapsed = after - before;

The high precision, monotonic clock would be there with MonoTime, and Duration
would give you a high precision duration between two MonoTimes. It wouldn't be
in ticks internally, but hecto-nanoseconds is plenty precise for almost all
cases (and more precise than most system clocks). So, you don't lose precision
(at most, you lose a bit of accuracy when converting from system ticks to
hnsecs if the system ticks aren't a multiple of 10), and we get rid of all of
this confusion with TickDuration vs Duration as well as the issues with
TickDuration not using the same conventions as the rest of core.time or
std.datetime.

And for those who really, really want to deal with durations in ticks (which
should be very rare), we can just expose MonoTime's internal ticks as an
integral value for them to do whatever is they're looking to do.

The few functions in Phobos which use TickDuration (like
std.datetime.benchmark) would then be made to return Duration instead of
TickDuration (possibly using implicit conversions to ease the transition, but
we were already looking at moving benchmark to std.benchmark anyway, which
would be a prime opportunity to change its return type). And we would deprecate
TickDuration, which _would_ unfortunately break code, but the end result would
be cleaner and much easier to use - and well worth it IMHO. Having both
TickDuration and Duration has proven to be overly confusing, and it's
definitely made dealing with benchmark worse.

I've been debating this sort of change for a while now, but after yet another
discussion on it in https://github.com/D-Programming-Language/druntime/pull/711
, I'm convinced that we'd be far better off if we made these changes.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 24 2014
parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11989


Martin Nowak <code dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code dawg.eu



Given how simple the explanation for the new MonoTime is, I'm very much in
favor of this. Getting rid of the second duration type is a huge bonus too.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 28 2014