[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Exposing subsecond precision in current-seconds

From: felix . winkelmann
Subject: Re: Exposing subsecond precision in current-seconds
Date: Thu, 30 Apr 2020 12:11:31 +0200

> Fair enough, but the original question was about having subsecond info
> about the current time.  So if I'm understanding you correctly this
> is something better developed as an egg, outside of core.

That's correct.

> Yeah, like I said in my other message, we could use the name
> current-process-milliseconds, like Racket;
> I like the name, because it's pretty clear what it does; it yields the
> number of milliseconds the process has been running for.
> We can make it a procedure without arguments, because that part of the
> Racket interface looks messy and confusing to me.

Yes, makes sense.

> > Something like "current-microseconds" is likely to be used in time
> > critical code (schedulers, profilers, etc.) You want to to be fast, ideally
> > not consing, especially on small or embedded systems.
> Yes, I agree that for those use cases you don't want to be consing.
> But then microsecond precision might be too much already, on 32 bit
> platforms.  A program that has an uptime of a month already needs 42
> bits to represent the time since startup in microseconds.

Unfortunately it does. Perhaps we have to put more thought into this.

> I think millisecond precision is enough for core, and I'm not sure we
> need microseconds.  So far, I think the use cases we've discussed aren't
> necessarily those of OP.

Probably not, but a SRFI-174 egg would be sufficient in that case, I'd say.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]