From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Refactoring of emacs-lisp/autoload.el Date: Wed, 13 Aug 2008 16:31:14 -0400 Message-ID: References: <20080812162333.GA7999@muc.de> <20080813141133.GC3010@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1218659704 28917 80.91.229.12 (13 Aug 2008 20:35:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Aug 2008 20:35:04 +0000 (UTC) Cc: Glenn Morris , Chong Yidong , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 13 22:35:55 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KTN17-0006r7-6b for ged-emacs-devel@m.gmane.org; Wed, 13 Aug 2008 22:32:25 +0200 Original-Received: from localhost ([127.0.0.1]:44191 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KTN0B-0005cQ-1O for ged-emacs-devel@m.gmane.org; Wed, 13 Aug 2008 16:31:27 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KTN06-0005ZJ-AZ for emacs-devel@gnu.org; Wed, 13 Aug 2008 16:31:22 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KTN04-0005Wk-57 for emacs-devel@gnu.org; Wed, 13 Aug 2008 16:31:21 -0400 Original-Received: from [199.232.76.173] (port=34055 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KTN03-0005WS-Uu for emacs-devel@gnu.org; Wed, 13 Aug 2008 16:31:19 -0400 Original-Received: from smtp-01.arnet.com.ar ([200.45.191.24]:33718) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KTN01-0007sw-W8 for emacs-devel@gnu.org; Wed, 13 Aug 2008 16:31:18 -0400 Original-Received: (qmail 5474 invoked from network); 13 Aug 2008 20:29:28 -0000 Original-Received: from unknown (HELO ceviche.home) (190.30.131.157) by 0 with SMTP; 13 Aug 2008 20:29:28 -0000 Original-Received: by ceviche.home (Postfix, from userid 20848) id 8296870134; Wed, 13 Aug 2008 16:31:14 -0400 (EDT) In-Reply-To: <20080813141133.GC3010@muc.de> (Alan Mackenzie's message of "Wed, 13 Aug 2008 14:11:33 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:102417 Archived-At: >> 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