Re: Refactoring of emacs-lisp/autoload.el

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> No, this was not a bug.  This section is present to speed up the refresh
>> of the loaddefs.el file, so that files that don't have other entries in
>> loaddefs.el don't have to be opened&scanned when they haven't changed
>> since the last time we refreshed loaddefs.el.
>> So calc/calc-aent.el should probably be mentioned in this list so as to
>> avoid having to open&scan it when it hasn't changed.

> OK.  I haven't yet characterised fully the criterion for a file being in
> this list.  I'm looking at that now.

Normally, all files should appear in loaddefs.el: either they have their
own section or they're in the "nothing to declare" section.
If there are a couple files not mentioned there, it's not tragic, tho.

The goal is that running "cd emacs/lisp; make autoloads" after
loaddefs.el has just been updated should only need to scan loaddefs.el,
and check the timestamp of all the .el files, and can then return
without reading any of the other (unchanged) elisp files, so that "make
autoloads" is almost immediate when it has nothing to do.

> Ah..  I hadn't properly understood the loop through the existing entries
> of loaddefs.el.  This is surely to minimise the searching within
> loaddefs.el, which is very slow if it's done clumsily.

That loop was fairly inefficient.

> My strategy when inserting a new entry into loaddefs.el is to start
> searching from the current position in that file.  So if the source files
> are processed in alphabetical order, the newer autoload.el should be just
> as fast (or, at least, fast enough).

Yes, that sounds fine.

>> The second case used to be unusably slow and I made it a lot faster
>> around Emacs-21 (or so), so now it's fast enough: please test it after
>> changing a handful of files, just to make sure that it's not
>> significantly slower than before.

> I'll test it.  Could you suggest a typical test scenario, please?  How
> many source files should I touch to test this?  3, 10, 30, 100?

Yes, 10, 30, 0, that sounds fine.

> I agree with all that.  I've been taking as much care as possible.

Great.

> But I know nothing of its use by 3rd party packages.  Do you know of
> any such uses, or is this a "there are probably some" situation?

I know I use it in sml-mode and haskell-mode and I know mh-e uses it as
well, but all three use it via batch-update-autoloads, so it should work
just fine.  I just expect other uses since there are ;;;###autoload
cookies for other entry points.  But indeed, I do not know of
concrete examples.


        Stefan