On 21/12/2010, at 2:17 PM, Jim Lloyd wrote: > On Mon, Dec 20, 2010 at 6:08 PM, john skaller <[email protected]> > wrote: > > On 21/12/2010, at 9:33 AM, Jim Lloyd wrote: > > Yes, de-allocation is one of the big motivating factors for us, primarily > > in our long-lived daemon applications. > > If you're doing individual de-allocations instead of whole-pool > deallocations, why are you using pools? > [I mean why do you want to use pools :] > > We're not yet using pools and currently we don't do individual > de-allocations. One of our uses of Judy is a symbol table, i.e. a > bidirectional mapping between strings and tokens. This table only grows. This > is fine in our batch applications but is an issue in our long-lived daemons > where it is an apparent slow leak. We can delete the entire table and start > fresh but we need a fast way to do this. Even if we could somehow make > individual de-allocations fast, I'm concerned about heap fragmentation. A > separate pool for the symbol table would address both problems.
Right. So that's even a bit harder: I'd accept your overhead on allocations but desire a deallocator without the overhead since my system does do individual de-allocations, but it does them "in bulk" where RT performance is noticeable. Actually .. my system has provision for using a completely distinct collector for each object, and thus supporting pools and pool de-allocation .. but that doesn't apply to the Judy arrays providing the infra-structure: tricky making the GC infrastructure itself gc-collectable :) Hmm, there is only one other transparent solution I can think of: TLS. That doesn't require locking by the user, no idea how the compiler/os handle it though. Traditionally TLS is expensive. You'd go back to the store the allocator in a TLS variable each operation model. If you're using any C style I/O with errno crud, you're using TLS already. Actually, malloc() has to use synchronisation already so you're already paying a performance hit for synchronisation, it used to use mutex locks but today I don't know, it seems a good candidate for "lock free" operation to me. -- john skaller [email protected] ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ Judy-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/judy-devel
