bug#38629: 25.2; garbage-collect doesn't reclaim large *compilation*

[Peter Ludemann]

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.