> From: Michał Kondraciuk <
k.mi...@zoho.com>
> Date: Mon, 2 Apr 2018 13:57:26 +0200
>
> Basically, when I run the sexp below in emacs -Q, Emacs keeps allocating
> a lot of memory. In 10 minutes, it goes from 18 MB to over 200 MB.
>
> (while t
> (with-temp-buffer
> (setq buffer-undo-list nil)
> (insert "a")))
>
>
> Calling garbage-collect afterwards or even inside the body of the loop
> doesn't help (except the loop obviously runs slower, so after 10
> minutes, Emacs uses ~100 MB of memory).
What do you mean by "afterwards"? The while-loop never ends, so
there's no "afterwards" AFAIU. Am I missing something?
To answer your question: yes, I think this is expected, given that you
set buffer-undo-list to nil (what is the purpose of that, btw?). If
you either delete that line or change it to set buffer-undo-list to t,
you will see a very different picture, as far as the Emacs memory
footprint is concerned.
> So I want to know if this behavior is expected for some reason? Does
> Emacs reuse this memory somehow (to make future allocations faster)?
When Emacs ends up requesting more memory from the OS, it usually
doesn't release that memory when it is no longer needed, but keeps it
in the process's address space and reuses it if/when it needs more
memory. Buffer text allocation and deallocation is treated
differently, in that when a buffer is killed, the memory used for its
text is returned to the OS, which is why deleting the line that sets
buffer-undo-list has the effect it does, I think.
Is there some real-life issue behind this experiment?