|
From: | Paul Eggert |
Subject: | bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode |
Date: | Fri, 29 Apr 2022 15:45:44 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |