Bug 11989 – Phase out TickDuration

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.

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.

The monotonic clock type was introduced in: https://github.com/dlang/druntime/pull/847 And there's a PR to deprecate TickDuration: https://github.com/dlang/druntime/pull/2886

@schveiguy created dlang/dmd pull request #15024 "Fix issue 11989 -- deprecate TickDuration, it's no longer used anywhere." fixing this issue: - Fix issue 11989 -- deprecate TickDuration, it's no longer used anywhere. https://github.com/dlang/dmd/pull/15024

Changing the title. MonoTime has been stable for almost a decade. Having the old title show up in the changelog would be confusing at this point.

dlang/dmd pull request #15024 "Fix issue 11989 -- deprecate TickDuration, it's no longer used anywhere." was merged into master: - a2f630ffd458ac3200fb8a779cec26e88ae2d767 by Steven Schveighoffer: Fix issue 11989 -- deprecate TickDuration, it's no longer used anywhere. https://github.com/dlang/dmd/pull/15024

Oh, nice. The last time that I tried to do this, I ran into deprecation messages from templates that really shouldn't have been triggering deprecation messages (IIRC from code that could use either Duration or TickDuration), and I concluded that the compiler was going to need some improvements before it could be done. I'm not sure if that issue was https://issues.dlang.org/show_bug.cgi?id=23800 or something else, but at least you figured out how to make it work.