diff options
| author | Jonathan Bradley <jcb@pikum.xyz> | 2024-12-17 16:10:30 -0500 |
|---|---|---|
| committer | Jonathan Bradley <jcb@pikum.xyz> | 2024-12-17 16:15:05 -0500 |
| commit | 1dc3bc5db3b3ba60399bee4753abe2f78374a2dd (patch) | |
| tree | eaad96f0a30010c00294a687658f6f6e421f0e03 /pktmr.h | |
| parent | 33484cccdea2790721fb20f75588d1ed4fb53017 (diff) | |
pktmr: first-pass, all macros, no IMPL
Diffstat (limited to 'pktmr.h')
| -rw-r--r-- | pktmr.h | 27 |
1 files changed, 27 insertions, 0 deletions
@@ -0,0 +1,27 @@ +#ifndef PK_PKTMR_H +#define PK_PKTMR_H + +#include <time.h> + +/* 2024-12-17 JCB + * I have read that in more recent Linux kernels, _MONOTONIC and _REALTIME + * do not require syscalls, while all of the other calls can. + * In testing on my personal machine, this seems to hold true. Using + * CLOCK_PROCESS_CPUTIME_ID consistently elapsed thousands of nanoseconds, + * even with no work between sequential _start() and _stop() calls. + * Meanwhile, the same test with _MONOTONIC elapsed only tens of nanoseconds. + * Consider replacing explicit usage with a define for more user control. + */ + +/* struct pk_tmr */ +struct pk_tmr { + struct timespec b; // begin + struct timespec e; // end +}; + +#define pk_tmr_start(tmr) { clock_gettime(CLOCK_MONOTONIC, &tmr.b); } +#define pk_tmr_stop(tmr) { clock_gettime(CLOCK_MONOTONIC, &tmr.e); } +#define pk_tmr_duration_double(tmr) ((1000.0 * tmr.e.tv_sec + 1e-6 * tmr.e.tv_nsec) - (1000.0 * tmr.b.tv_sec + 1e-6 * tmr.b.tv_nsec)) +#define pk_tmr_duration_nano(tmr) ((((uint64_t)tmr.e.tv_sec * (uint64_t)1000000000) + tmr.e.tv_nsec) - (((uint64_t)tmr.b.tv_sec * (uint64_t)1000000000) + (uint64_t)tmr.b.tv_nsec)) + +#endif /* PK_PKTMR_H */ |
