From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs memory management and sluggishness Date: Sat, 27 Jul 2019 16:20:06 +0300 Message-ID: <83sgqrlim1.fsf@gnu.org> References: <87k1c44n7y.fsf@telefonica.net> <83d0hwm0fc.fsf@gnu.org> <87ef2b4pti.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="236336"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: =?utf-8?Q?=C3=93scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 27 15:20:30 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hrMcg-000zGm-0S for ged-emacs-devel@m.gmane.org; Sat, 27 Jul 2019 15:20:30 +0200 Original-Received: from localhost ([::1]:45798 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hrMce-0000nJ-W2 for ged-emacs-devel@m.gmane.org; Sat, 27 Jul 2019 09:20:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60462) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hrMcX-0000n0-F2 for emacs-devel@gnu.org; Sat, 27 Jul 2019 09:20:22 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40125) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hrMcV-0008KB-IC; Sat, 27 Jul 2019 09:20:20 -0400 Original-Received: from [176.228.60.248] (port=3656 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hrMcS-0004BU-9b; Sat, 27 Jul 2019 09:20:17 -0400 In-reply-to: <87ef2b4pti.fsf@telefonica.net> (message from =?utf-8?Q?=C3=93scar?= Fuentes on Sat, 27 Jul 2019 14:36:25 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:238951 Archived-At: > From: Óscar Fuentes > Cc: emacs-devel@gnu.org > Date: Sat, 27 Jul 2019 14:36:25 +0200 > > > Is there any correlation between the lag and the GC cycles? (Turn on > > garbage-collection-messages to see.) > > Ok. Too bad that the gc messages are not appended to *Messages*. > > Indeed, the lag is caused by gc. > > > If it does, then there's only > > one problem to investigate: why you have frequent GC cycles. > > > > And what is your value of gc-cons-threshold? > > (setq gc-cons-threshold (* 20 1000 1000)) > > setting it to (* 2 1000 1000)) shortens the gc pauses, but I have the > impression that they occur with the same frecuency. OK, so it's one down, one to go; and I guess you should consider lowering the threshold. > > Having said all that, it isn't clear to me that an RSS of 1.1 GB per > > se is something exceptional in a long-running session. E.g., the > > Emacs 26.2.90 session where I'm typing this, which is running for 44 > > days, shows an RSS of 360 MB with VM Size of 514 MB, and this is a > > 32-bit build of Emacs --with-wide-int. So your 1.1 GB is not > > necessarily a sign of a problem. > > Until now my experience was similar. Emacs memory usage increased > steadily to about 400 MB but then it stayed there. This is the first time > that I see it over 1 GB. The largest memory usage I observed until now > was 700 MB, but that was visiting very large PDF files and navigating > through many pages. > > Since my previous message RSS increased 30 MB. So I guess we have a memory leak somewhere. Not sure if we have good ways of finding them. I think I'd suggest to update to the latest master, and then track your memory footprint, waiting for the problem to happen and taking notes of what features you invoke. Once the problem happens again, it would be good to know which features were activated and which commands invoked since the last checkpoint, so we could look into what these features/commands do.