[Cython] [cython-users] freelist benchmarks

Stefan Behnel stefan_ml at behnel.de
Mon Feb 25 10:17:25 CET 2013


Hi,

thanks for looking through it.

David Roe, 25.02.2013 00:00:
> I changed the current type pointer check to look at tp_basicsize instead.
> 
>> That made it work for almost all classes in lxml's own Element hierarchy,
>> with only a couple of exceptions in lxml.objectify that have one additional
>> object field. So, just extending the freelist support to use two different
>> lists for different struct sizes instead of just one would make it work for
>> all of lxml already. Taking a look at Sage to see how the situation appears
>> over there would be interesting, I guess.
> 
> I found some chains of length 5.  This could be shortened to 4 by putting
> the freelist at the level of Element (which is where you most care about
> speed of object creation).

It's substantially easier to keep it in the top-level base class, though.
Otherwise, we'd need a new protocol between inheriting types as I
previously described. That add a *lot* of complexity.


> SageObject
>     -> Element (_parent attribute and cdef methods)
>     -> Vector (_degree)
>     -> FreeModuleElement (_is_mutable)
>     -> FreeModuleElement_generic_dense (_entries)
> 
> SageObject
>     -> Element (_parent attribute and cdef methods)
>     ->sage.structure.element.Matrix (_nrows)
>     -> sage.matrix.matrix.Matrix (_base_ring)
>     -> Matrix_integer_dense (_entries)

Ok, so even for something as large as Sage, we'd apparently end up with
just a couple of freelists for a given base type. That really makes it
appear reasonable to make that number a compile time constant as well. I
mean, even if you *really* oversize it, all you loose is the static memory
for a couple of pointers. On a 64 bit system, if you use a freelist size of
8 objects and provision freelists for 8 differently sized subtypes, that's
8*8*8 bytes in total, or half a KB, statically allocated. Even a hundred
times that size shouldn't hurt anyone. Unused subtype freelists really take
almost no space and won't hurt performance either.


> This does look cool to have though.

It definitely is.

Stefan



More information about the cython-devel mailing list