bug#65491: [PATCH] Improve performance allocating vectors

[Stefan Monnier]

> - isn't vector_free_list twice as big as it needs to be?
> - 4096 bytes for vector blocks seems a tad small

AFAIK this number was chosen arbitrarily and we never tried to tune it,
so there's probably room for improvement, indeed.
Note that many vectors will be small (they're really Lisp structs), tho.

> - to what extent are we duplicating the work done by modern libc allocators
> (very generously including glibc here)?

We are exactly duplicating that code (and poorly so, as is the rule),
but there's a reason for it: we need to allocate those vectors within
specifically marked/known address ranges so that our conservative
stack scanning can distinguish "potential valid pointer to a vector"
from "definitely not a pointer to a vector".

It would be nice if we could more or less literally copy the code of
a good malloc library.

[ The previous vector allocation code was even more costly because every
  vector allocation came together with allocation and insertion of a new
  node in the red-black tree where we keep track of which ranges of
  memory hold which kind of data.  ]

It's important to improve efficiency of vector allocation because it
allows us to get rid of specialized allocations we're using for other
Lisp types.  E.g. we got rid of the specialized `marker_block`s we used
to use for markers and overlays (and a handful of more esoteric data
types), and next in line are the `symbol_block`s and `interval_block`s.


        Stefan