GNU bug report logs -
#79182
30.1; emacs becomes progressively less responsive up to become unusable
Previous Next
Full log
View this message in rfc822 format
> From: Francesco Potortì <pot <at> potorti.it>
> Date: Wed, 06 Aug 2025 16:57:19 +0200
> Cc: 79182 <at> debbugs.gnu.org
>
> >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?
This bug report was last modified 6 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.