GNU bug report logs - #79182
30.1; emacs becomes progressively less responsive up to become unusable

Previous Next

Package: emacs;

Reported by: Francesco Potortì <pot <at> potorti.it>

Date: Wed, 6 Aug 2025 09:32:02 UTC

Severity: normal

Found in version 30.1

Full log


Message #29 received at 79182 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Francesco Potortì <pot <at> potorti.it>
Cc: 79182 <at> debbugs.gnu.org
Subject: Re: bug#79182: 30.1;
 emacs becomes progressively less responsive up to become unusable
Date: Wed, 06 Aug 2025 22:09:47 +0300
> From: Francesco Potortì <pot <at> potorti.it>
> Date: Wed, 06 Aug 2025 19:06:03 +0200
> Cc: 79182 <at> debbugs.gnu.org
> 
> But is it normal that I get a warning when reading a file whose size exceeds a given threshold, but not when a hidden buffer grows over 3GB?

We could discuss this separately.  One problem with the growing buffer
case is that the growth is gradual, unlike reading a large file, which
happens in one go.  So a warning could be too late.

> And is it normal that a 3GB buffer which is occasionally appended to has such a big impact on Emacs, even on a system with 64GB real memory available and largely unused?

I don't think it's the buffer text itself.  Look at your memory
report: you also had 2 GB of intervals and 1.2 GB of cons cells.  I
think it's those that caused the expensive GC, because GC needs to
traverse all those objects.  Buffer text itself has only a minor
effect on GC.

> And is it normal that such frequent garbage collections are not detected and signaled, with possibly a hint of what might be the most common causes and remedies?

Again, we could discuss the possible ways of detecting this and
perhaps warning the user.  We never had any such warnings until now.




This bug report was last modified today.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.