timestamp resolution

[Robin Jarry]

Morten Brørup, May 21, 2026 at 12:43:
> Then I suggest we introduce an unsigned clock type with much lower resolution.
> If it's 32 bit, it can handle an uptime of 136 years with one second resolution.
>
> Using lower resolution timestamps provides some performance benefits.
> Specifically, the number of memory store operations can be significantly reduced by not writing into a timestamp field if it already holds the same value.

I wonder if the cost of checking if the value changed before writing
defeats the performance gain, compared to writing without question.

Did you find any hotspots while profiling regarding timestamps? I think
this may be an unnecessary optimization.

> On the other hand...
> Using coarser timers does increase jitter, so instead of using seconds, some fraction of a second could be used.
> E.g. 1/16 of a second could handle an uptime of 8.5 years.
>
> Would the definition of such a type, and its inline support functions, go into the api/gr_clock.h header file, or would it go into a separate header file?

gr_clock.h is the correct place.

The only issue I may think of is that on some systems, clock_t can be
a floating number (double). Maybe we could replace the return value of
gr_clock_us() to a typedef we control?

	typedef uint64_t gr_time_us_t;

What do you think?

-- 
Robin

> Freshest if eaten before date on carton.