bug#65491: [PATCH] Improve performance allocating vectors

[Mattias Engdegård]

26 aug. 2023 kl. 16.55 skrev Stefan Monnier <monnier@iro.umontreal.ca>:

>> - 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.

That's definitely the case, and the same allocation mechanism is used for many 
other fairly small objects.

Another observation is that most vectorlike allocations are fixed-size. This is 
mostly true even for nominally variable-sized objects (vectors and records) 
because as you say, they are often used as (fixed-sized) structs.

We might want to segregate allocations by size entirely and cease splitting 
longer vectors. That, with larger and N-bit aligned blocks, would provide rapid 
access to common metadata from any object pointer. This may reduce GC costs; 
will have to look at that.

Naturally, allocation and GC costs must be considered together (and run-time, 
in case we change representation which is occasionally warranted).

> 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.

Yes, many important object types are fixed-sized vectorlike allocations. 
Allocations tend to be spikey in size; that's why vector_free_lists is so 
sparse and should probably be reformed.