Project

General

Profile

Actions

Task #2503

open

Optimize usage of steady_clock::now()

Added by Alex Afanasyev about 9 years ago. Updated about 9 years ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
Core
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

now() operation is relatively expensive and there are multiple usages of it in the forwarding pipelines and strategies. I don't know yet how, but we should consider optimizing it in some way.

The simplest way I can think of is to use a global variable that is set inside the monotonic_deadline_timer (or inside the global scheduler).

Actions #1

Updated by Junxiao Shi about 9 years ago

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.

Actions #2

Updated by Davide Pesavento about 9 years ago

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.

Actions #3

Updated by Alex Afanasyev about 9 years ago

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.

Actions

Also available in: Atom PDF