[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: Re: master afc0bfd380: Speed up loaddefs-generate on slow disks
Date: Fri, 03 Jun 2022 08:52:27 +0300

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  emacs-devel@gnu.org,
>   eggert@cs.ucla.edu
> Date: Thu, 02 Jun 2022 21:18:57 -0400
> Eli Zaretskii [2022-06-02 19:16:00] wrote:
> >> > I'm really surprised this is faster, even on slow disks.
> >> > Does anyone have a idea of why that is?
> > Isn't that clear?  file-newer-than-file-p calls 'stat' for both files,
> > and one of them is a loop invariant AFAIU.  Taking its time outside
> > the loop speeds up things (but perhaps not on GNU/Linux).
> Under GNU/Linux, I'd expect `stat` to be significantly faster than
> `file-attributes` (and the extra `stat` on the loop-invariant file
> should be especially fast since it should be as close as it gets w.r.t
> the caches (both OS-level and CPU-level)).

Yes, when 'stat' is a syscall.  On Windows, we issue at least 6
syscalls, more so if the file is on a networked volume.

> >> I didn't actually benchmark it -- either way is fast on my laptop.  But
> >> the old autoloads code did it with time-less-p, and Eli said that it was
> >> faster, so...  Perhaps Eli can report back whether it made a difference
> >> or not.
> > It did -- for the better.  Thanks.
> This suggests that the kind of change I suggested would make it even
> a bit faster, tho it should reduce the run time by less than 50%
> under Windows (because the time to do the `stat`s is apparently already
> >50% of the total).

I don't know how you deduce the 50% figure.  Look at w32.c:stat_worker
to see what we do on Windows to faithfully emulate 'stat' -- I have no
idea how this compares with the time required to cons a Lisp data
structure from the data, but it can well be that consing is much
faster.  The only sure way is to benchmark both alternatives.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]