Re: Emacs bzr memory footprint

[Stefan Monnier]

> This creates two-level fragmentation: the whole heap is fragmented as seen
> by malloc(), and allocated space is fragmented too, as seen by Emacs. Since

Yes.

> solid workload will consume 100M of the heap, the most of this 90M will be 
> re-used -

Exactly: so this fragmentation is not a serious problem in the sense
that this free memory can be (re)used by Emacs.

> but it will never freed.

Right, so it's a problem in the sense that this memory will not be
available to other processes.

While this is not perfect, I don't consider it to be a serious problem.
E.g. when people complain about Emacs using a lot of memory it's always
(until now and I think in Nix's case as well) a case of too much memory
being used because of something like a leak, and not just "Emacs doesn't
return its free memory to the OS".

E.g. in the case of Nix, I think it's pretty clear that Emacs should
never have gotten to the point where it used up 800MB of memory.

> Due to all of the above, I suspect that the mostly-copying collector, where 
> all
> small (say, < 4K) lisp (and only lisp) allocation requests are satisfied from
> 1M-4M areas, might have substantial advantages over plain mark&sweep scheme.

There's no argument that pretty anything else than mark&sweep is better
than mark&sweep in some significant respect.


        Stefan