Re: master afc0bfd380: Speed up loaddefs-generate on slow disks

[Lars Ingebrigtsen <larsi@gnus.org>]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> Maybe `file-newer-than-file-p` should accept a time value for one of the
>> two file names so we can speed this up further by refraining from
>> constructing a whole `file-attributes` only to reduce it down to
>> a single boolean?
>
> There's a longer discussion about these issues (i.e., reworking the
> functions in this area to be more efficient in these respects) in the
> bug tracker somewhere.  Paul had a bunch of ideas that I think we should
> pursue.  I forget which bug# -- perhaps Paul remembers; added to the CCs.

It's bug#55163, but to recap shortly (hehe) for new readers:

Our time functions return time values on a very inefficient format (a
four-element list), and we want to move (long term) to a more efficient
format (which is a single cons cell).  But we can't just change the
output from our current time functions, because that breaks a lot of
callers.  But we can introduce new functions that only return the
efficient format.

My point in bug#55163 is that we should see this as an opportunity to
overhaul functions in this area in general, and `file-attributes' is one
of those.  For instance, we could have a new function `file-attribute'
where you specify the data you actually want, like
(file-attribute file :modtime), and it'd just return that value.  (Or
more values if you say (file-attribute file :modtime :directoryp) etc.)

If we had that, our loop here would have been

(time-less-p output-time (file-attribute file :modtime))

and it would be maximally fast and efficient.

So I don't think we should touch `file-newer-than-file-p' in any way,
but instead wait for this new set of functions (which should be created
in one go so that everything fits together, and not piecemeal).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no