[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.
- Re: master afc0bfd380: Speed up loaddefs-generate on slow disks, Stefan Monnier, 2022/06/02
- Re: master afc0bfd380: Speed up loaddefs-generate on slow disks, Lars Ingebrigtsen, 2022/06/02
- Re: master afc0bfd380: Speed up loaddefs-generate on slow disks, Eli Zaretskii, 2022/06/02
- Re: master afc0bfd380: Speed up loaddefs-generate on slow disks, Stefan Monnier, 2022/06/02
- Re: master afc0bfd380: Speed up loaddefs-generate on slow disks,
Eli Zaretskii <=
- Re: master afc0bfd380: Speed up loaddefs-generate on slow disks, Stefan Monnier, 2022/06/03
- Re: master afc0bfd380: Speed up loaddefs-generate on slow disks, Eli Zaretskii, 2022/06/03
- Re: master afc0bfd380: Speed up loaddefs-generate on slow disks, Stefan Monnier, 2022/06/03
- Re: master afc0bfd380: Speed up loaddefs-generate on slow disks, Eli Zaretskii, 2022/06/03
Re: master afc0bfd380: Speed up loaddefs-generate on slow disks, Lars Ingebrigtsen, 2022/06/04
- Re: master afc0bfd380: Speed up loaddefs-generate on slow disks, Mattias EngdegÄrd, 2022/06/05
- Re: master afc0bfd380: Speed up loaddefs-generate on slow disks, Lars Ingebrigtsen, 2022/06/05
- Re: master afc0bfd380: Speed up loaddefs-generate on slow disks, Lars Ingebrigtsen, 2022/06/06
- Re: master afc0bfd380: Speed up loaddefs-generate on slow disks, Alan Mackenzie, 2022/06/06
- Re: master afc0bfd380: Speed up loaddefs-generate on slow disks, Lars Ingebrigtsen, 2022/06/06