Re: Proposal: block-based vector allocator

["Stephen J. Turnbull" <stephen@xemacs.org>]

Dmitry Antipov writes:
 > On 12/07/2011 05:52 PM, Stefan Monnier wrote:

 > > Yes.  And the design I propose is one that has proved to be such a good
 > > balance.
 > 
 > The design itself can't prove anything. The devil is in the details, and
 > implementation is the only thing that matters. My favorite GC textbook
 > (http://www.amazon.com/gp/product/1420082795) describes a tens of
 > very good designs, but doesn't provide any ready-to-use recipes to help
 > us solve memory usage issues.

I don't think you're going to solve the memory use issues by improving
vector allocation.  "Premature optimization is the root of all error."

 > Wrong. Among others, good design might (and should) try to improve the
 > spatial locality of allocated objects,

I (and I suspect Stefan) disagree with "should".  The goal is worthy,
but success difficult and unlikely: Emacs tend to end up with very
poor locality for many reasons.

As for the memory savings themselves, your benchmark is not
convincing: all it tells us that an allocation algorithm carefully
tuned to decreasing the size of a dumped Emacs can do so, a little.
But the amount of memory that can be saved in practice is rather small
compared to the level of memory usage that users complain about these
days.  "EMACS = 8 MB And Constantly Swapping" is a non sequitur, and
has been for almost 20 years for me.  So it does not tell us that it
will help with the problems being discussed in the "Memory again"
thread, among others.

If you want to keep working on it, fine -- every little bit helps, and
you might succeed.  But I don't think it should be a priority for
Emacs, and you are going to need to show more gains to make it worth a
somewhat more complex code base.