From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: emacs trying to load too many files at startup Date: Sat, 19 Nov 2005 22:07:48 +0200 Message-ID: References: <200511191831.jAJIVJTp026147@scanner2.ics.uci.edu> <200511191950.jAJJo0Tp029512@scanner2.ics.uci.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1132430906 16460 80.91.229.2 (19 Nov 2005 20:08:26 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 19 Nov 2005 20:08:26 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 19 21:08:25 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EdZ0E-0007KP-JV for ged-emacs-devel@m.gmane.org; Sat, 19 Nov 2005 21:08:02 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EdZ0D-0005Pr-VS for ged-emacs-devel@m.gmane.org; Sat, 19 Nov 2005 15:08:01 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EdZ04-0005PQ-Ik for emacs-devel@gnu.org; Sat, 19 Nov 2005 15:07:52 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EdZ03-0005P6-2y for emacs-devel@gnu.org; Sat, 19 Nov 2005 15:07:52 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EdZ02-0005P3-Vh for emacs-devel@gnu.org; Sat, 19 Nov 2005 15:07:51 -0500 Original-Received: from [192.114.186.20] (helo=nitzan.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EdZ02-00011v-PC for emacs-devel@gnu.org; Sat, 19 Nov 2005 15:07:51 -0500 Original-Received: from HOME-C4E4A596F7 (IGLD-80-230-28-201.inter.net.il [80.230.28.201]) by nitzan.inter.net.il (MOS 3.6.5-GR) with ESMTP id BZC18696 (AUTH halo1); Sat, 19 Nov 2005 22:07:43 +0200 (IST) Original-To: Dan Nicolaescu In-reply-to: <200511191950.jAJJo0Tp029512@scanner2.ics.uci.edu> (message from Dan Nicolaescu on Sat, 19 Nov 2005 11:49:57 -0800) 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:46277 Archived-At: > Cc: emacs-devel@gnu.org > From: Dan Nicolaescu > Date: Sat, 19 Nov 2005 11:49:57 -0800 > > > The easiest and the most accurate way of answering that is to put a > > breakpoint in stat64, and then do a bt each time the breakpoint > > triggers. > > stat64 is a syscall, so you cannot set a breakpoint on it. Of course you can put a breakpoint on stat64, since it's a normal function that issues a syscall, not the syscall itself. If you tried and failed, it's probably because glibc plays all kinds of redirection and weak-alias games. Try "rbreak stat64", and you will see the name of the _real_ function that issues the syscall. But that's an aside, it sounds like you found the culprit. > I set a breakpoint on Fexpand_file_name instead and that lead to: > > (gdb) xbacktrace > "locate-file-internal" > "locate-file" > "mapcar" > "command-line" > "normal-top-level" > > > And that seems to indicate this code: > > ;; Convert preloaded file names to absolute. > (setq load-history > (mapcar (lambda (elt) > (if (and (stringp (car elt)) > (not (file-name-absolute-p (car elt)))) > (cons (locate-file (car elt) load-path > load-suffixes) > (cdr elt)) > elt)) > load-history)) Do we know that this code alone is responsible for those 2000 extra calls to stat64? Is it possible that there's some other code besides Fexpand_file_name that causes some of those calls? > This is the change that introduced the above code: > > revision 1.381 > date: 2005/10/21 17:20:45; author: rms; state: Exp; lines: +11 -0 > (command-line): Convert library names in `load-history' to absolute file names. > > The question is: should anything be done about this? I don't know. Anyone? I'm guessing that this is converting non-absolute file names in loaddefs.el into absolute file names.