On Wed, Mar 08, 2006 at 04:42:58AM -0700, Jim Cromie wrote: > Nicholas Clark wrote: > >On Tue, Mar 07, 2006 at 10:47:26PM +0000, Dave Mitchell wrote: > >>On Tue, Mar 07, 2006 at 11:45:01AM -0800, Nicholas Clark wrote: > >>>+=head2 Allocate OPs from arenas > >>Erm, isn't the code already there, if PL_OP_SLAB_ALLOC is defined? > > > >Er. I thought. I'd not looked at that. > > > >And then, no, that's not what I was thinking about. It seems to allocate > >all > >kinds of ops from a big slab of memory, and has fairly complex routines to > >knock it down into chunks of the correct size. I was thinking of how the SV > >body arena code works, which has 1 slap per type, and maintains a free list > >for each type, which makes freeing and reallocation much simpler, and > >allocation a bit simpler than the slab code. > > > >Nicholas Clark > > > If I got you right, youre thinking of arena_roots for UNOPs, BINOPs, > PMOPs, COPs etc, from which OP-trees are built. This sounds bad from a > cache proximity standpoint, despite the relative simplicity vs the > OP_SLAB_ALLOC stuff.
Yes, I was thinking that. OP_SLAB_ALLOC is not the default currently, and I doubt anyone is really using it in production. Given how it never re-uses memory until it frees the slab, I suspect it also uses more memory than the current (default) malloc()/ free() implementation, because I suspect it's unlikely that all ops in a slab get freed. Nicholas Clark
