GNU bug report logs -
#65491
[PATCH] Improve performance allocating vectors
Previous Next
Full log
Message #35 received at 65491 <at> debbugs.gnu.org (full text, mbox):
> - 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
This bug report was last modified 1 year and 264 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.