From mboxrd@z Thu Jan 1 00:00:00 1970 Path: quimby.gnus.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: dired too SLOW Date: Fri, 8 Mar 2002 14:17:51 -0800 (PST) Message-ID: <200203082217.g28MHpN00754@shade.twinsun.com> References: <200203012353.PAA14261@roadkill.rose.hp.com> <2950-Sat02Mar2002102858+0200-eliz@is.elta.co.il> <200203082107.g28L7HO03332@wijiji.santafe.edu> NNTP-Posting-Host: quimby.gnus.org X-Trace: quimby.gnus.org 1015625939 8243 80.91.224.244 (8 Mar 2002 22:18:59 GMT) X-Complaints-To: usenet@quimby.gnus.org NNTP-Posting-Date: 8 Mar 2002 22:18:59 GMT Cc: buff@hpbs9968.boi.hp.com, emacs-devel@gnu.org Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16jShV-00028q-00 for ; Fri, 08 Mar 2002 23:18:58 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16jSgq-00055p-00; Fri, 08 Mar 2002 17:18:16 -0500 Original-Received: from alcor.twinsun.com ([198.147.65.9]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16jSgS-00052a-00; Fri, 08 Mar 2002 17:17:52 -0500 Original-Received: from shade.twinsun.com ([192.54.239.27]) by alcor.twinsun.com (8.12.1/8.12.1) with ESMTP id g28MHpPB013093; Fri, 8 Mar 2002 14:17:51 -0800 (PST) Original-Received: (eggert@localhost) by shade.twinsun.com (8.11.6+Sun/8.11.6) id g28MHpN00754; Fri, 8 Mar 2002 14:17:51 -0800 (PST) Original-To: rms@gnu.org In-reply-to: <200203082107.g28L7HO03332@wijiji.santafe.edu> (rms@gnu.org) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: quimby.gnus.org gmane.emacs.devel:1816 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1816 > From: Richard Stallman > Date: Fri, 8 Mar 2002 14:07:17 -0700 (MST) > > I had this problem and commented-out the invocation of "df", > from: insert-directory.el > > It is very strange that df should be so slow. > Normally it is very fast. What is causing it to be slow? There are many reasons df could be slow. I have often run into automounters or NFS servers that take a long time to respond to a resolvepath or a statvfs system call (which df uses), even when they respond quickly to a stat system call (which ls uses). This can be caused by stale NFS file handles, for example. I've heard that some HP-UX releases require that every mountable filesystem must actually be mounted, or df will hang. This might be what buff is running into, since he's at HP. In some cases (the Solaris 2.6 automounter comes to mind), the problem can be worked around by doing the stat (or ls) before the statvfs (or df). It might be wise to modify Emacs to do that. Also, perhaps Emacs could put a short timeout on its invocation to 'df', and report that the usage is unknown if 'df' fails to respond in time. On older BSD hosts like SunOS 4.1.3, df must do a sync before doing a statvfs to get reasonably accurate results. This can be a real performance hit. (I think SVR4 /usr/ucb/df does the sync for no good reason -- the sync is there only because it was needed on older BSD-style systems.) Perhaps the Emacs PROBLEMS section can suggest that users use GNU fileutils df on older SVR4 and SunOS 4.x hosts, to avoid that problem on those hosts. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel