bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Paul Eggert <eggert@cs.ucla.edu>]

On 4/29/22 12:53, Eli Zaretskii wrote:

>> Lars makes a good point that common idioms like 
>> (file-attribute-modification-time (file-attributes F)) generate 
>> unnecessary garbage. And it's more than just GC overhead: at a lower 
>> level, 'statx' on GNU/Linux can be significantly more efficient than 
>> plain 'stat' when retrieving just a subset of stat info (such as, just 
>> the file timestamp).
> 
> This is (almost) unrelated to timestamps.  The same case can be made
> about almost every individual file attribute, at least theoretically.

Yes, we could separate the idea. File timestamps are the worst offenders 
for GC, so they provide much of the motivation for this other idea.


>   Taking the file's modification
> time as an example, are there any important use cases except
> determining if a file is older or newer than another?

Yes, for example lots of Lisp code takes a file timestamp, keeps it 
somewhere, then examines it later to print or to compare to another 
timestamp. See, for example, how ido-file-name-all-completions compares 
ctime (the cached timestamp) to mtime (the file timestamp).

> we already have a primitive for that

Sure, but file-newer-than-file-p is not adequate for many routine 
calculations involving file timestamps. It can't do the sort of caching 
described above, for example. My impression is that 
file-newer-than-file-p suffices for less than half of the sort of 
routine things people need to do with file timestamps.