Re: Time resolution in Emacs

[Max Nikulin <manikulin@gmail.com>]

On 26/04/2022 02:27, Paul Eggert wrote:
> On 4/25/22 09:54, Max Nikulin wrote:
> 
>> on Linux while file metadata are in cache, timestamps may have high 
>> time resolution. When later fetched from disk they may have coarse 
>> resolution, e.g. whole seconds.
> 
> Yes, that is a known bug in older Linux kernels. As I understand it, the 
> bug was fixed many years ago. (It broke GCC builds circa 2004[1] so 
> there was a good deal of motivation to fix it.) I expect this problem is 
> no longer relevant; if I'm wrong, Eli's suggestion would help to work 
> around it.
> 
> [1]: 
> https://linux.kernel.narkive.com/XLtQbTzQ/linux-2-6-nanosecond-time-stamp-weirdness-breaks-gcc-build 

Thank you. I do not remember why I was aware of such peculiarity and 
considered it as a feature. I have not expected that it was fixed.

Accidentally I have found the following proposal to add fsinfo() system 
call to the Linux kernel. It should expose timestamp resolution, but 
likely the patches was not merged. I have not read the discussion though.

https://lwn.net/Articles/827934/
David Howells <dhowells-AT-redhat.com> VFS: Filesystem information [ver 
#21] Mon, 03 Aug 2020 14:36:21 +0100

On 26/04/2022 00:02, Eli Zaretskii wrote:
 >> Date: Mon, 25 Apr 2022 23:54:58 +0700
 >> From: Max Nikulin
 >
>> As to 16ms resolution, at least for `benchmark-run' I would like to have 
>> finer granularity.
> 
> Do you really run benchmarks that end in a matter of milliseconds?

It may be enough for quick estimations during comparison of methods 
having order of magnitude difference in running time.

Sometimes it is necessary to measure duration of particular calls 
without repetition.

> In any case, measuring a time interval with high precision doesn't
> necessarily need a fine-granular wall clock.

My experience is that it is even less probable to find monotonic clock 
or performance counters implemented when some legacy method is used for 
wall time.