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 _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
