unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Peter Ludemann <peter.ludemann@gmail.com>
To: Noam Postavsky <npostavs@gmail.com>
Cc: 38629@debbugs.gnu.org
Subject: bug#38629: 25.2; garbage-collect doesn't reclaim large *compilation*
Date: Mon, 16 Dec 2019 15:37:55 -0800	[thread overview]
Message-ID: <CAHjfyZ3nLSENf7TWmYC9Aer_UAiU3H48+7NhAGxM6-yLVgVohg@mail.gmail.com> (raw)
In-Reply-To: <87a77scprp.fsf@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1318 bytes --]

Upgrading to Emacs 26.3 seems to have fixed the memory problem but now
there's another problem ... emacs becomes incredibly sluggish (almost
unuseable) -- top(1) shows 70-100% CPU utilization even when the
compilation step isn't outputting anything. (I use GNU parallel on the
tests, with options to preserve the output order, so output happens at
intervals.)

The compilation command is "find ... | sort | nice parallel -j 8
--keep-order --group -L80" (on a 4 CPU machine).
I tried reducing the number of parallel jobs to 3, but that didn't help.

Should I open a new bug for this? If so, what information can I collect, to
help determine the cause?

On Mon, 16 Dec 2019 at 06:24, Noam Postavsky <npostavs@gmail.com> wrote:

> Peter Ludemann <peter.ludemann@gmail.com> writes:
>
> > I ran a large compilation (to the *compilation* buffer) (232,701 lines,
> > 52M).
>
> > In GNU Emacs 25.2.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.21)
> >  of 2017-09-22, modified by Debian built on lgw01-amd64-050
> > Windowing system distributor 'The X.Org Foundation', version
> 11.0.11906000
> > System Description: Ubuntu 18.04.3 LTS
>
> I think this is a variant of Bug#26952 - "repeated buffer insertion
> (e.g. yank-rectangle) consumes excessive memory (4GB+ for 90MB of
> text)".  I recommend upgrading to version 26.
>
>
>

[-- Attachment #2: Type: text/html, Size: 2207 bytes --]

  parent reply	other threads:[~2019-12-16 23:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-15 19:58 bug#38629: 25.2; garbage-collect doesn't reclaim large *compilation* Peter Ludemann
2019-12-16  4:16 ` bug#38629: Loading/killing the compilation output doesn't lose memory Peter Ludemann
2019-12-16 14:24 ` bug#38629: 25.2; garbage-collect doesn't reclaim large *compilation* Noam Postavsky
2019-12-16 16:48   ` Peter Ludemann
2019-12-16 23:37   ` Peter Ludemann [this message]
2019-12-17  0:19     ` Peter Ludemann
2019-12-17 13:14       ` Noam Postavsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHjfyZ3nLSENf7TWmYC9Aer_UAiU3H48+7NhAGxM6-yLVgVohg@mail.gmail.com \
    --to=peter.ludemann@gmail.com \
    --cc=38629@debbugs.gnu.org \
    --cc=npostavs@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).