summaryrefslogtreecommitdiff
path: root/pktmr.h
diff options
context:
space:
mode:
authorJonathan Bradley <jcb@pikum.xyz>2024-12-17 16:10:30 -0500
committerJonathan Bradley <jcb@pikum.xyz>2024-12-17 16:15:05 -0500
commit1dc3bc5db3b3ba60399bee4753abe2f78374a2dd (patch)
treeeaad96f0a30010c00294a687658f6f6e421f0e03 /pktmr.h
parent33484cccdea2790721fb20f75588d1ed4fb53017 (diff)
pktmr: first-pass, all macros, no IMPL
Diffstat (limited to 'pktmr.h')
-rw-r--r--pktmr.h27
1 files changed, 27 insertions, 0 deletions
diff --git a/pktmr.h b/pktmr.h
new file mode 100644
index 0000000..9245373
--- /dev/null
+++ b/pktmr.h
@@ -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 */