bug#65491: [PATCH] Improve performance allocating vectors

[Ihor Radchenko]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> First of all, let's leave bignums out of this entirely. They are not relevant 
> here.
>
> Second, please do not motivate any perceived performance problem from
> benchmarks found on the internet, especially anything derived from the
> Gabriel benchmarks. This includes the benchmarks in ELPA.

> That said, vectorlike object allocation in general is definitely
> relevant and can certainly be improved but I'm not persuaded by the
> proposed patch. Please do not apply it right away.

I have no problem with this and I have supplied more relevant benchmarks
with Org and with composition (as suggested by Eli).

Of course, the problem is not with bignums - it just revealed the
inefficiency with array iteration I tried to address. If more can be
done with vectorlike allocation, it will be even better.

> However, the important part is not the patch but the problem it highlights, 
> and here there is evidently plenty to do. 
>
> For example:
>
> - isn't vector_free_list twice as big as it needs to be?

AFAIR, trying to reduce this array size was the first thing I tried.
When I touched VECTOR_BLOCK_SIZE, I got segfaults and compilation
failures. (Do note that I am missing understanding about the motivation
behind this constant).

> - to what extent are we duplicating the work done by modern libc allocators 
> (very generously including glibc here)?
> - next_vector is a dangerously unstable concoction of C undefined behaviour

Isn't vector_free_list following the pattern used across alloc.c? For
example, Fcons uses a similar idea with holding pre-allocated memory as
a chain of pointers.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>