On 15 Jul 2025, at 14:23, Eli Zaretskii wrote:

Given the above description, why did you decide the leak is in
redisplay_internal?

 39,652,925  72% - redisplay_internal (C function)
  1,797,080   3%  + eval
    279,056   0%  + jit-lock-function
     66,632   0%  + which-key--hide-popup-on-frame-size-change
     24,752   0%    mode-line-default-help-echo
     11,328   0%  + menu-bar-update-buffers

This is taken from just now. It seems like a lot of memory goes there. Given that I have 2Gbs of usage beyond ~40mb reporting I'd suspect something fishy is happening there.

And on paper everything looks fine - with single Elisp buffer Emacs reports: 57MiB as reserved for objects, ~30mb of Conses. There is 900Mb of total system usage which makes it top memory eater.

For context - I run HiDPI and refresh rate system though (4400x2400 with 60hz - was 144hz before), which might explain why redisplay memory rise is happening quicker than for others.

FWIW, I'm using Emacs 30.1.90 all the time, with sessions that last
several weeks, and its memory footprint, after leveling at several
hundred MB never grows more, certainly not at the rate you describe.
So either this is a macOS-specific problem, or something else is at
work here (perhaps one of the many packages you have activated?).

I'm quite sure that this is the problem with MacOS/NS implementation.

I've experienced similar behavior in raw and patched versions and rarely can hold a session for more than 2 days. Usually when Emacs went dead it went dead and that was it, I blamed it on setup, only today caught bloat when I was investigating performance deterioration. (and searching for it the general complain is "well Emacs on MacOS is slower than on Linux").

Well, for starters please explain why you think it's
redisplay_internal that leaks. Also, if you can try older versions of
Emacs, please see if the same issue exists there.

I'm quite positive it does, because I've observed this for at least 2 years. Today it's much better than it was before, but still it bloats. I didn't think about running -Q, and that was simple enough to confirm that:

  1,561,924  54% + timer-event-handler
  1,185,948  41% - redisplay_internal (C function)
    287,011  10%  + jit-lock-function
     79,104   2%    file-remote-p
     13,312   0%  + kill-this-buffer-enabled-p
      8,184   0%    mode-line-default-help-echo

Usage is 230MiB of memory, reported 5MiB. leaks app (MacOS malloc leak tracer) reports barely 229kb of leaked memory and it reports 37MiB malloced out of 139MiB (usage dropped while I was writing this e-mail). Finally - redisplay_internal is the only place I saw memory going out (and just noticed that redisplay itself is good enough to start GC every couple seconds - 17GCs over 10s test period using -Q instance).

And finally, what version of Emacs are you using and how did you build
it? Is that Emacs 30.1.90 pretest built from the pretest tarball, or
is it something else?

MacOS built with emacs-plus - built through Homebrew from emacs-30 branch right now, but I've seen this performance degredation over time on emacs-mac and emacs through MacPorts.

Best,
Przemysław Alexander Kamiński