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 Slowdown Date: Mon, 09 Mar 2015 18:16:18 +0200 Message-ID: <83pp8i5ep9.fsf@gnu.org> References: <87pp8i75nk.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1425917818 15300 80.91.229.3 (9 Mar 2015 16:16:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Mar 2015 16:16:58 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Mar 09 17:16:50 2015 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 1YV0MK-00014a-7b for geh-help-gnu-emacs@m.gmane.org; Mon, 09 Mar 2015 17:16:48 +0100 Original-Received: from localhost ([::1]:44171 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YV0MJ-0006mS-Fl for geh-help-gnu-emacs@m.gmane.org; Mon, 09 Mar 2015 12:16:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YV0M8-0006mM-74 for help-gnu-emacs@gnu.org; Mon, 09 Mar 2015 12:16:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YV0M4-00060X-Tq for help-gnu-emacs@gnu.org; Mon, 09 Mar 2015 12:16:36 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:37693) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YV0M4-00060B-MY for help-gnu-emacs@gnu.org; Mon, 09 Mar 2015 12:16:32 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NKY00900D06G800@a-mtaout23.012.net.il> for help-gnu-emacs@gnu.org; Mon, 09 Mar 2015 18:16:31 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NKY009KYD7IBL90@a-mtaout23.012.net.il> for help-gnu-emacs@gnu.org; Mon, 09 Mar 2015 18:16:31 +0200 (IST) In-reply-to: <87pp8i75nk.fsf@newcastle.ac.uk> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 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:103090 Archived-At: > From: phillip.lord@newcastle.ac.uk (Phillip Lord) > Date: Mon, 09 Mar 2015 11:48:47 +0000 > > I am suffering a rather disasterous slowdown in my emacs. It feels like > a memory leak, as my emacs gets slower over time. It mostly seems to be > affected auctex, where there is considerable lag in cursor movement to > the point that typing becomes difficult. For starters, customize garbage-collection-messages to a non-nil value, and see if Emacs announces GC while cursor movement is sluggish. > I've tried the profiler. After a long run, I find this for memory usage: > > - redisplay_internal (C function) 2,853,658,459 79% > - and 2,682,842,214 74% > - directory-files 110,636 0% > - concat 74,740 0% > regexp-quote 57,316 0% > file-directory-p > > which is a bit strange. I have no idea when "and" should be getting > called so much. The top of the CPU profile looks like this... Forget the memory-usage profile, it doesn't measure what you think it does, and is mostly useless, except in very specialized situations, and then for people who really understand what this means (I don't). If you want to test the hypothesis of a memory leak, it's easier to look at your Emacs process's virtual memory size, either in 'top' or in "M-x proced". Take a few snapshots of the value and try to correlate that with the values reported by 'garbage-collect'. If those values stay approximately stable, or go down, but the VSS of the process goes up, you can suspect a memory leak; otherwise the problem is elsewhere. (Personally, I wouldn't pursue the memory leak avenue first, especially if this is an official release, not a development version of Emacs: I think other possible reasons are much more probable. But that's me.) > One other thing that I have noticed is that define-global-minor-mode > adds to the post-command-hook. Currently, this means that my > post-command-hook looks like this.... > > > (global-font-lock-mode-check-buffers global-lentic-mode-check-buffers > global-pabbrev-mode-check-buffers yas-global-mode-check-buffers > global-eval-pulse-mode-check-buffers > global-auto-complete-mode-check-buffers > projectile-global-mode-check-buffers > global-wide-column-mode-check-buffers > wide-column-post-command-hook-function phil-show-paren-mode-check > winner-save-old-configurations mode-local-post-major-mode-change) > > which is an awful lot of functions to be called on every keypress. I > realise that I may have gone a bit overboard here, especially as five of > those functions are mine! The question is: what do those hook do, on average? If they are very lightweight (profile them to see if they are), then this isn't your villain. Also, try removing most of the hooks when you see sluggish operation, and see if that brings any significant speedup; if not, these aren't what you are looking for.