digitalmars.D.bugs - [Issue 11989] New: Introduce a new monotonic clock type and phase out TickDuration
- d-bugmail puremagic.com (61/61) Jan 24 2014 https://d.puremagic.com/issues/show_bug.cgi?id=11989
- d-bugmail puremagic.com (11/11) Jan 28 2014 https://d.puremagic.com/issues/show_bug.cgi?id=11989
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
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