From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.devel Subject: Re: Recent recentf slowdown due to "/ftp:..." Date: Sat, 04 Jul 2009 13:08:06 +0200 Message-ID: <87d48gln8p.fsf@escher.local.home> References: <878wjghh57.fsf@escher.local.home> <871vp7d5gz.fsf@gmx.de> <87hby3qxkg.fsf@escher.local.home> <87r5wzzcnq.fsf@escher.local.home> <87y6r6t3kb.fsf@escher.local.home> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1246705784 20225 80.91.229.12 (4 Jul 2009 11:09:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 Jul 2009 11:09:44 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 04 13:09:37 2009 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 1MN37h-0007x4-HM for ged-emacs-devel@m.gmane.org; Sat, 04 Jul 2009 13:09:37 +0200 Original-Received: from localhost ([127.0.0.1]:33536 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MN37g-00087l-P5 for ged-emacs-devel@m.gmane.org; Sat, 04 Jul 2009 07:09:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MN36d-0007Tg-KI for emacs-devel@gnu.org; Sat, 04 Jul 2009 07:08:31 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MN36Y-0007RG-De for emacs-devel@gnu.org; Sat, 04 Jul 2009 07:08:30 -0400 Original-Received: from [199.232.76.173] (port=58768 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MN36X-0007Qi-JW for emacs-devel@gnu.org; Sat, 04 Jul 2009 07:08:26 -0400 Original-Received: from main.gmane.org ([80.91.229.2]:56223 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MN36W-0003RQ-Mc for emacs-devel@gnu.org; Sat, 04 Jul 2009 07:08:25 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MN36T-0005hG-D4 for emacs-devel@gnu.org; Sat, 04 Jul 2009 11:08:21 +0000 Original-Received: from i59f566b5.versanet.de ([89.245.102.181]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 04 Jul 2009 11:08:21 +0000 Original-Received: from stephen.berman by i59f566b5.versanet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 04 Jul 2009 11:08:21 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 70 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: i59f566b5.versanet.de User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/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:112006 Archived-At: On Fri, 03 Jul 2009 13:21:24 +0200 Stephen Berman wrote: > On Thu, 02 Jul 2009 10:56:09 +0200 Stephen Berman wrote: > >> On Fri, 26 Jun 2009 09:11:11 +0200 Stephen Berman wrote: >> >>> *Messages*. But at startup there was again a pause when the echo area >>> displayed the message "Cleaning up the recentf list...". This time it >>> lasted about 30 seconds, then startup completed and Emacs appears to be >>> running normally. However, the complete recentf message is "Cleaning up >>> the recentf list...done (0 removed)", so I assume 30 seconds is too long >>> and indicative of a problem. With this emacs process running I started >>> another Emacs with my initializations, including the same recentf file, >>> and it came up without a pause. Same thing with `emacs -Q --eval >>> "(recentf-mode 1)"'. >> >> I continue to see this misbehavior, i.e. a ca. 30 stillstand while the >> recentf list is being cleaned up, even with 0 files removed. Today I >> reproduced it with -Q -l test.el, the latter file consisting solely of >> this: >> >> (custom-set-variables >> '(recentf-mode t)) >> >> This was with my recentf file. Again there was a ca. 30 second pause >> (one file was removed). I have not been able to reproduce the pause by >> repeating this with a new emacs process but the same login session. >> Does anyone have an idea what the problem could be, or a suggestion >> about how to try and track it down? > > I've narrowed it down to the above sexp as the entire content of > ~/.emacs and this ~/.recentf: > > ,---- > | ;;; Automatically generated by `recentf' on Fri Jul 3 12:53:43 2009. > | > | (setq recentf-list > | '( > | "/ftp:anonymous@ftp.bla.org:/" > | )) > | > | (setq recentf-filter-changer-current 'nil) > | > | > | ;; Local Variables: > | ;; coding: utf-8-emacs > | ;; End: > `---- > > The above ftp site is made up but it still resulted in a 30 second pause > (I have real ftp sites in my normal recentf-file). Again, this only > happens with the first Emacs started in a given login session, and I've > only been experiencing this since updating from the trunk after the 23.1 > branch was created. That update included the new Tramp update and Tramp > appears to be implicated by the above ftp line, though, as I already > mentioned, adding (setq tramp-verbose 8) to ~/.emacs produces no Tramp > debug buffer. I have confirmed that while the problem occurs with my first post-branch build, GNU Emacs 23.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.14.4) of 2009-06-23 on escher (and still with current build of 2009-06-30), it does not occur with my last pre-branch build, GNU Emacs 23.0.94.2 (i686-pc-linux-gnu, GTK+ Version 2.14.4) of 2009-06-14 on escher. Whatever causes the pause seems to leave a trace in resident memory that prevents the pause, so testing requires a fresh login session. Because of this, unfortunately, I do not have time to revert from CVS to find the problematic change. Unless someone can suggest another way to locate it, I'll just add this to the bugtracker and hope it gets fixed. Steve Berman