GNU bug report logs - #65491
[PATCH] Improve performance allocating vectors

Previous Next

Full log

Message #32 received at 65491 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 65491 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#65491: [PATCH] Improve performance allocating vectors
Date: Sat, 26 Aug 2023 14:54:55 +0000

Mattias Engdegård <mattias.engdegard <at> 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>

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.