Subject: Re: bug#79182: 30.1; emacs becomes progressively less responsive up to become unusable

From: Eli Zaretskii <[email-masked]>
Date: Wed, 06 Aug 2025 18:37:05 +0300

> From: Francesco Potortì <[email-masked]>
> Date: Wed, 06 Aug 2025 16:57:19 +0200
> Cc: [email-masked]
> 
> >Yet another aspect is the memory footprint of Emacs: if it is very
> >large, perhaps your system runs out of physical memory and starts
> >paging?
> 
> I have RSS of about 5GB for Emacs and about 6GB for Firefox, which should not be a lot given that I have 64 GB physical memory.  Anyway, I killed Firefox and I got some little improvement, but not so much.
> 
> >And finally, set garbage-collection-messages non-nil and see if Emacs
> >says it's running GC when it becomes not responsive.
> 
> I just did that and yes, when Emacs stalls it is always because of the garbage collector.

Aha!

> Estimated Emacs Memory Usage
> 
>    4.9 GiB  Total Buffer Memory Usage
>    3.5 GiB  Overall Object Memory Usage
>    291 MiB  Reserved (But Unused) Object Memory
>     22 MiB  Memory Used By Global Variables
>    6.4 MiB  Memory Used By Symbol Plists
>    134 KiB  Total Image Cache Size
> 
> Object Storage
> 
>    2.2 GiB  Intervals
>    1.2 GiB  Conses
>     51 MiB  Strings
>     22 MiB  Vectors
>    2.5 MiB  Symbols
>    217 KiB  Buffer-Objects
>     11 KiB  Floats
> 
> Largest Buffers
> 
>    3.1 GiB  *debug tramp/scp evaalapi-as*
>    549 MiB  *debug tramp/scp fencepost.gnu.org*
>    321 MiB  *debug tramp/scp casapot*
>    312 MiB  *debug tramp/scp aaloa*
>    287 MiB   *message-viewer RMAIL*
>    181 MiB  *debug tramp/scp rootevaal*
>    125 MiB  *debug tramp/scp evaalapi-eu*

That's a _huge_ session.

> After deleting all the *debug tramp buffers, the problem seems to have disappeared.  I have used Emacs for some minutes after that, and it behaves normally.  The huge *debug tramp/scp evaalapi-as* buffer was relative to a file that was modified, on a shaky Internet connection.  So that is the first suspect.  All the other *debug tramp buffers were relative to unmodified files or deleted buffers.
> 
> This is the memory report after deleting all the Tramp buffers (was very fast):
> 
> Estimated Emacs Memory Usage
> 
>    456 MiB  Reserved (But Unused) Object Memory
>    388 MiB  Total Buffer Memory Usage
>    112 MiB  Overall Object Memory Usage
>     22 MiB  Memory Used By Global Variables
>    6.4 MiB  Memory Used By Symbol Plists
>     73 KiB  Total Image Cache Size
> 
> Object Storage
> 
>     51 MiB  Strings
>     31 MiB  Conses
>     22 MiB  Vectors
>    6.1 MiB  Intervals
>    2.5 MiB  Symbols
>    194 KiB  Buffer-Objects
>     11 KiB  Floats

This is much more reasonable, similar to what I have here.

> Largest Buffers
> 
>    287 MiB   *message-viewer RMAIL*
>     40 MiB  *eww*
>     11 MiB   *message-viewer NOTIZIE*
>    9.7 MiB   *code-conversion-work*
>    6.1 MiB  RMAIL
>    5.2 MiB  *info*
>    3.3 MiB   *message-viewer GNU*
>    1.5 MiB  loaddefs.el.gz
>    1.4 MiB   *message-viewer hacker*
>    1.2 MiB   *jka-compr-wr-temp*
>      1 MiB  *Messages*
>      1 MiB  log
>    915 KiB  dpkg.log.1
>    875 KiB  *mail*
>    753 KiB  dpkg.log.2.xz
>    622 KiB  pot.bib
>    593 KiB  *info*<5>
>    593 KiB  *info*<3>
>    593 KiB  *info*<4>
>    592 KiB  *info*<2>
> 
> Largest Variables
> 
>    2.2 MiB  woman-topic-all-completions
>    1.4 MiB  undo-equiv-table
>    1.3 MiB  anything-candidate-cache
>    1.3 MiB  kill-ring
>    1.3 MiB  kill-ring-yank-pointer
>    1.2 MiB  anything-c-man-pages
>      1 MiB  load-history
>      1 MiB  ucs-normalize-hangul-translation-alist
>    814 KiB  mailcap--computed-mime-data
>    725 KiB  url-domsuf-domains
>    659 KiB  package-archive-contents
>    618 KiB  easy-menu-converted-items-table
>    399 KiB  Info-toc-nodes
>    314 KiB  uni-confusable-table
>    269 KiB  help-definition-prefixes
>    251 KiB  current-load-list
>    216 KiB  face--new-frame-defaults
>    203 KiB  mailcap-mime-extensions
>    135 KiB  mail-aliases
>    126 KiB  global-map

So I guess the mystery is solved?