NFD

How bad is this problem? Please run a benchmark to find out what percentage of CPU cycles are used by now() calls.

One way to do this benchmark is: run NFD in QEMU or similar platform where the CPU can be traced, and count the number of CPU cycles when now() is on the stack.

As far as I can see, steady_clock uses clock_gettime and CLOCK_MONOTONIC. This may or may not call into the kernel depending on a few things, and the overhead of a syscall might not be negligible. On Linux we could use instead CLOCK_MONOTONIC_COARSE, which is entirely done in userspace in the VDSO, assuming it has an acceptable resolution for us (it's usually around 1ms). The selection can in fact be done at startup using clock_getres: if the _COARSE variant is good enough, use that, otherwise fallback to the more accurate but slower CLOCK_MONOTONIC.

But I don't think now() performance is that bad actually. Right now, NFD spends the great majority of its time on crypto operations, therefore addressing #2488 first would likely yield a bigger benefit.

The reason I put low priority and no target version is for the exactly the reason indirectly and directly by Junxiao and Davide (I should have phrased issue description more carefully): I think (and have no proof yet) that the overhead of now() is not negligible and may be it makes sense to optimize this part in some point in the future. For near future (next couple of versions), we have bigger fish to optimize and should focus on those. I would like to keep this issue just as a reminder.