Consider using GHC.Clock.getMonotonicTimeNSec

[sjakobi]

http://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-Clock.html#v:getMonotonicTimeNSec

corsis/clock#56 indicates that it is quite a bit faster than getTime Monotonic – at least on Linux.

[harendra-kumar]

@sjakobi I updated the clock repo PR with my analysis of GHC vs clock.

streamly is no longer using the clock package, it has its own clock implementation, though the code works in the same way as in the clock package. So it should have similar performance. I am not sure if we can use a more efficient way to collect the system call results. If we cannot do that we can use the GHC API when available.

I think we should add the getTime benchmarks to streamly as well to see where we stand with regard to performance of the getTime API in streamly. Sometimes we are much worse due to a missing INLINE or some other stupid mistake.

[harendra-kumar]

Recording my update from the clock package:

It seems both clock and GHC are using exactly the same system call i.e. clock_gettime with a CLOCK_MONOTONIC clock type to get the time.

• https://github.com/corsis/clock/blob/ef60bd51a3587a173adf565c33bf2886df6e3842/System/Clock.hsc#L131
• https://gitlab.haskell.org/ghc/ghc/blob/master/rts/posix/GetTime.c#L88

The difference may be due to the setup code to get the results. The clock package allocates memory using alloca:

getTime clk = allocaAndPeek $! clock_gettime $! clockToConst clk

While GHC is using StgWord64:

StgWord64 getMonotonicNSec(void)
{
#if defined(HAVE_CLOCK_GETTIME)
    struct timespec ts;
    int res;

    res = clock_gettime(CLOCK_ID, &ts);
    if (res != 0) {
        sysErrorBelch("clock_gettime");
        stg_exit(EXIT_FAILURE);
    }
    return (StgWord64)ts.tv_sec * 1000000000 +
           (StgWord64)ts.tv_nsec;

StgWord64 may be more efficient than alloca. Though, it should make any practical difference only if we use the getTime call very very often.

[sjakobi]

Thanks for investigating @harendra-kumar!

That the difference is due to memory allocations seems quite plausible!