From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Refactoring of emacs-lisp/autoload.el Date: Wed, 13 Aug 2008 14:11:33 +0000 Message-ID: <20080813141133.GC3010@muc.de> References: <20080812162333.GA7999@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1218636599 9868 80.91.229.12 (13 Aug 2008 14:09:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Aug 2008 14:09:59 +0000 (UTC) Cc: Glenn Morris , Chong Yidong , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 13 16:10:44 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 1KTH3d-00012H-1W for ged-emacs-devel@m.gmane.org; Wed, 13 Aug 2008 16:10:37 +0200 Original-Received: from localhost ([127.0.0.1]:38880 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KTH2g-0007qb-Og for ged-emacs-devel@m.gmane.org; Wed, 13 Aug 2008 10:09:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KTH2b-0007qS-S6 for emacs-devel@gnu.org; Wed, 13 Aug 2008 10:09:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KTH2a-0007qG-Ud for emacs-devel@gnu.org; Wed, 13 Aug 2008 10:09:33 -0400 Original-Received: from [199.232.76.173] (port=55576 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KTH2a-0007qD-QG for emacs-devel@gnu.org; Wed, 13 Aug 2008 10:09:32 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:1502 helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KTH2a-00035A-AU for emacs-devel@gnu.org; Wed, 13 Aug 2008 10:09:32 -0400 Original-Received: (qmail 49232 invoked by uid 3782); 13 Aug 2008 14:09:28 -0000 Original-Received: from acm.muc.de (pD9E23E2A.dip.t-dialin.net [217.226.62.42]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Wed, 13 Aug 2008 16:09:26 +0200 Original-Received: (qmail 7023 invoked by uid 1000); 13 Aug 2008 14:11:33 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.6-4.9 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:102405 Archived-At: Hi, Stefan! Thanks for the comments: On Tue, Aug 12, 2008 at 04:09:04PM -0400, Stefan Monnier wrote: > > (ii) It produces more consistent result in the comment sections of loaddefs.el > > etc. In particular: > > o - The lines that identify the source file now always (rather than just > > sometimes) give a file name relative to the "starting directory" (usually > > .../lisp). E.g.: [ .... ] > I'm not sure why you think it's an improvement: the previous behavior > was to use a file name relate to where the name was placed (i.e. > relative to the file in which the entry is created). In my opinions, > relative file names placed in files should generally be relative to the > file in which they appear rather than relative to the "top of the > project". It's just I hadn't understood why it was being done. I see now that it was being done right, and I've changed my code to do it the same way. > > o - The final section (which records files which had no autoload > > symbols) no longer includes any files for which there is a normal > > section higher up. For example, in lisp/loaddefs.el at the > > moment, "calc/calc-aent.el" violates this rule. I have assumed > > that this is a bug. > 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. > > (iii) The new autoload.el runs quite a lot faster than the old one. :-) Here > > are some comparitive timings, done under fair conditions on my 1.2 GHz > > Athlon box: > > OLD: NEW: > > real 1m11.502s real 0m40.729s > > user 0m55.141s user 0m24.519s > > sys 0m15.981s sys 0m15.998s > There are 2 ways to run this code: one is to rebuild loaddefs.el from > scratch, the other is to update a preexisting loaddefs.el (typically > just after "cvs update"). With "make bootstrap" you care about the > first, otherwise you care about the second. I.e. I care about the > second ;-) 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. 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). > 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? > > This is a speedup of ~75%. > That's great. In parallel bootstrap builds, the loaddefs.el is > sometimes on the critical path, so that's a very welcome improvement. > I can't easily browse your patch with the machine I'm using right now, > so I can't comment on the actual code. The current code (mostly due to > yours truly, sadly) is not very satisfactory indeed, so as long as the > new code is fully compatible with the various ways autoload.el is used > (i..e not just by Emacs itself but by other external 3rd party > packages), and as long as it doesn't significantly slow down the > "no/few changes" case, I see no reason not to install it, I agree with all that. I've been taking as much care as possible. 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? > Stefan -- Alan Mackenzie (Nuremberg, Germany).