From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: package.el Date: Tue, 22 May 2007 11:21:58 +0900 Message-ID: <87iral7g3d.fsf@uwakimon.sk.tsukuba.ac.jp> References: <2cd46e7f0705101124r72000f78xdf05d18ca815ca57@mail.gmail.com> <17991.47259.210100.801472@localhost.localdomain> <85d50wq6a9.fsf@lola.goethe.zz> <1122B7CB-0AA2-475F-847B-A5D0B2FA2B05@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1179799886 18881 80.91.229.12 (22 May 2007 02:11:26 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 22 May 2007 02:11:26 +0000 (UTC) Cc: David Reitter , emacs-devel@gnu.org To: tromey@redhat.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 22 04:11:23 2007 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 1HqJqM-0002VS-Ik for ged-emacs-devel@m.gmane.org; Tue, 22 May 2007 04:11:22 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HqJqM-00087J-31 for ged-emacs-devel@m.gmane.org; Mon, 21 May 2007 22:11:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HqJqH-00083I-Rd for emacs-devel@gnu.org; Mon, 21 May 2007 22:11:17 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HqJqF-0007ut-Dk for emacs-devel@gnu.org; Mon, 21 May 2007 22:11:17 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HqJqF-0007uX-4d for emacs-devel@gnu.org; Mon, 21 May 2007 22:11:15 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HqJqE-0004dK-Fq for emacs-devel@gnu.org; Mon, 21 May 2007 22:11:14 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id 9E7631535AC; Tue, 22 May 2007 11:11:10 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D43181A2965; Tue, 22 May 2007 11:21:59 +0900 (JST) In-Reply-To: X-Mailer: VM 7.17 under 21.5 (beta27) "fiddleheads" (+CVS-20070324) XEmacs Lucid X-detected-kernel: 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:71565 Archived-At: Tom Tromey writes: > I'm reasonably sure that I don't want to do this scanning every time > Emacs starts up. But I admit I have not benchmarked the scanning > approach. XEmacs does do a lot of scanning, and it has been a source of complaints. But IIRC the problem was that XEmacs keeps each package in a separate directory (actually, several of them, since it emulates the standard layout of GNU Emacs with subdirectories of lisp/ for package Lisp, subdirectories of etc/ for miscellaneous package data, and so on). Searching through that to determine which subdirectories are actually package directories and should be on load-path was what took the most time. The original scheme was fully recursive requiring stats of all files to find subdirectories for possible recursion. Substantial savings were achieved by limiting the search depth (currently to children of the lisp/ directory itself). Currently most XEmacs users seem to consider the additional startup time acceptable, especially on fast machines with Unix-style file systems, but I suspect for even a moderate number of packages, Emacs users would detect a lag, since Emacs's startup is snappier than XEmacs's. David Kastrup had several suggestions for how to speed up XEmacs's start time, which would probably apply to package.el, too. IIRC they were to collect package auto-autoloads and custom-loads into a single file, and to put all package Lisp into a single directory to avoid recursive searching.