From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: emacs slow on dired renaming Date: Sat, 05 Apr 2014 12:22:30 +0300 Message-ID: <83fvls871l.fsf@gnu.org> References: <871txekiid.fsf@capuchin.co.uk> <87a9c28clz.fsf@capuchin.co.uk> <87lhvl6xog.fsf@capuchin.co.uk> <8761motb26.fsf@capuchin.co.uk> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1396689766 8868 80.91.229.3 (5 Apr 2014 09:22:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Apr 2014 09:22:46 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Apr 05 11:22:40 2014 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WWMo8-0006kO-3x for geh-help-gnu-emacs@m.gmane.org; Sat, 05 Apr 2014 11:22:36 +0200 Original-Received: from localhost ([::1]:53870 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WWMo7-0002Qb-DX for geh-help-gnu-emacs@m.gmane.org; Sat, 05 Apr 2014 05:22:35 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:59496) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WWMnr-0002QO-Ky for help-gnu-emacs@gnu.org; Sat, 05 Apr 2014 05:22:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WWMnl-0008VJ-CM for help-gnu-emacs@gnu.org; Sat, 05 Apr 2014 05:22:19 -0400 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:50987) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WWMnl-0008Si-4T for help-gnu-emacs@gnu.org; Sat, 05 Apr 2014 05:22:13 -0400 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0N3J00300VKCVD00@mtaout26.012.net.il> for help-gnu-emacs@gnu.org; Sat, 05 Apr 2014 12:20:47 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N3J00330WMNEL50@mtaout26.012.net.il> for help-gnu-emacs@gnu.org; Sat, 05 Apr 2014 12:20:47 +0300 (IDT) In-reply-to: <8761motb26.fsf@capuchin.co.uk> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.182 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:96998 Archived-At: > From: Robert Marshall > Date: Sat, 05 Apr 2014 09:50:09 +0100 > > > If you try renaming a single file with "M-x rename-file RET", does it > > also take 2 sec? > > > There's no apparent delay On a restart or in a session where moving from Dired is already very slow? If the latter, then the actual file I/O is not the reason for the slowdown, and I suggest to selectively disable portions of your ~/.emacs to find out what causes this. It could be frequent GC, for example (set garbage-collection-messages non-nil to see if it is), or something else that causes excessive processing. Or maybe you have a lot of buffers visiting files in a directory being renamed, in which case Dired will loop over all those files and rename their default-directory, which could be expensive for a very large number of such buffers. Btw, I don't understand this part of your profile: - dired-in-this-tree 10841 38% + let 23 0% This says that dired-in-this-tree takes 1/3rd of the run time. But dired-in-this-tree is just this: (defun dired-in-this-tree (file dir) ;;"Is FILE part of the directory tree starting at DIR?" (let (case-fold-search) (string-match-p (concat "^" (regexp-quote dir)) file))) So I wonder how come it takes such a large proportion of the time. As another possible hint, does the number of times dired-create-files is called (26704) make sense? Do you really have such a large number of files in the tree you are moving? Can you produce a profile for moving a single file (which you say takes about 2 sec)?