From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David De La Harpe Golden Newsgroups: gmane.emacs.devel Subject: Re: Emacs 23.0 is much slower starting than Emacs 22.3 Date: Thu, 23 Oct 2008 23:47:51 +0100 Message-ID: <4900FF17.2000203@harpegolden.net> References: <20081022091136.GB924@muc.de> <20081022151444.GE924@muc.de> <48FF58FB.6000302@harpegolden.net> <20081022211202.GA1037@muc.de> <49001F5A.7040402@harpegolden.net> <20081023090908.GB2666@muc.de> <4900ACF9.7060501@harpegolden.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1224802101 1138 80.91.229.12 (23 Oct 2008 22:48:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Oct 2008 22:48:21 +0000 (UTC) Cc: acm@muc.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 24 00:49:21 2008 connect(): Connection refused 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 1Kt8zY-0001GA-Ka for ged-emacs-devel@m.gmane.org; Fri, 24 Oct 2008 00:49:21 +0200 Original-Received: from localhost ([127.0.0.1]:42729 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kt8yR-0002Kx-Qq for ged-emacs-devel@m.gmane.org; Thu, 23 Oct 2008 18:48:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kt8yN-0002KT-0Z for emacs-devel@gnu.org; Thu, 23 Oct 2008 18:48:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kt8yK-0002J8-Jp for emacs-devel@gnu.org; Thu, 23 Oct 2008 18:48:05 -0400 Original-Received: from [199.232.76.173] (port=37677 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kt8yK-0002J5-Dq for emacs-devel@gnu.org; Thu, 23 Oct 2008 18:48:04 -0400 Original-Received: from harpegolden.net ([65.99.215.13]:60018) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kt8yF-0007il-W0; Thu, 23 Oct 2008 18:48:00 -0400 Original-Received: from [87.198.54.44] (87-198-54-44.ptr.magnet.ie [87.198.54.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "David De La Harpe Golden", Issuer "David De La Harpe Golden Personal CA rev 3" (verified OK)) by harpegolden.net (Postfix) with ESMTP id BECF88120; Thu, 23 Oct 2008 23:47:53 +0100 (IST) User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) In-Reply-To: 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:104915 Archived-At: Eli Zaretskii wrote: >> So FWIW probably the problem is in the find-file call path rather than >> anything desktop.el is doing in particular > > Sounds plausible. Next question: is the slow-down connected in any > way with decoding the buffer? To see if this is a factor, you could > compare 180 calls to insert-file-contents with the same number of > calls to insert-file-contents-literally, in both Emacs 22 and 23. > > TIA Haven't got to that that - however, insert-file-contents may only account for < 10% of the total time spent in find-file-noselect-1, at least according to the elp profiler. Though it may not work right at all on C functions? (note doubled call count) - However, I then wrapped the insert-file-contents call in find-file-noselect-1 in an elisp helper function (find-file-noselect-1-h below) and got a quasi-consistent figure for it, see [1] below for results, suggesting it may really be that small? [Aside: Also turns out upping gc-cons-threshold shaves 2 secs off that 7 sec time for 180 files. Just maybe opening a bunch of files one after the other causes the memory usage to grow rapidly, causing the gc to kick in... so that's one, though probably fairly necessary, slowdown] [1] (n.b. this was without upped gc-cons-threshold) Function Name CallCt ElapsedTime AverageTime find-file-noselect 180 5.4325150000 0.0301806388 find-file-noselect-1 180 4.4660830000 0.0248115722 insert-file-contents 361 0.3358580000 0.0009303545 find-file-noselect-1-h 180 0.3062349999 0.0017013055 make-local-variable 10477 0.0153409999 1.464...e-06 abbreviate-file-name 730 0.0095040000 1.301...e-05 kill-buffer 185 0.0034050000 1.840...e-05 kill-local-variable 1084 0.0008220000 7.583...e-07 normal-backup-enable-predicate 180 0.0006289999 3.494...e-06 erase-buffer 361 0.0003230000 8.947...e-07 set-buffer-multibyte 181 0.0001579999 8.729...e-07 [2[ gc-cons-threshold to 1G find-file-noselect 180 3.2771109999 0.0182061722 find-file-noselect-1 180 2.5760030000 0.0143111277 insert-file-contents 361 0.3392750000 0.0009398199 find-file-noselect-1-h 180 0.3094899999 0.0017193888 make-local-variable 10477 0.0170539999 1.627...e-06 abbreviate-file-name 730 0.0157539999 2.158...e-05 kill-buffer 185 0.0047130000 2.547...e-05 kill-local-variable 1084 0.0008650000 7.979...e-07 normal-backup-enable-predicate 180 0.0007309999 4.061...e-06 erase-buffer 361 0.0003520000 9.750...e-07 set-buffer-multibyte 181 0.0001799999 9.944...e-07