On 21/12/2010, at 9:33 AM, Jim Lloyd wrote: > > On 21/12/2010, at 8:17 AM, Jim Lloyd wrote: > > Yes, our app is multi-threaded . Actually, we have several different > applications that share common code and Judy is integral to all of these > applications. Some of these apps are batch and some are long-lived daemons. > All of them scale well up to 16 cores. >
I am so glad to here this, gives me confidence in choice of Judy for my own app. > The same method would work for multi-threaded apps with a lock to protect > the allocator: pretty ugly and much higher performance cost. > > No, that's not feasible. We can have literally millions of Judy arrays in one > process. One global lock shared by all Judy arrays would kill the performance. > Yea, it would. Actually you only need one lock per pool.. but it's still bad. > In this context, a small extra cost adding a new address to the Judy data > structures > would be acceptable: allocation is already expensive, so an extra 5-10% > overhead > would be OK. > > That's my assumption. I'd expect the added overhead to be under 1% when > amortized over the total cost (i.e. including the cost of the allocations). > There should be no extra cost to the Judy*Get operations since these don't > ever allocate. A Judy*Insert operation will be marginally more expensive, > even in the case where the key already exists and no allocation is necessary, > due to an additional argument on each stack frame. This is the worst case for > cost, because the other case of a Judy*Insert where the key doesn't exist > will have cost dominated by the cost of the memory allocation. > Unfortunately it's hard to predict, since compilers like gcc can do fantastic job on code C and if you make a tiny change halve the performance. One extra machine register to pass the pointer down could cost 1% or 50%. > Do you need to de-allocate as well? Often pools are used to avoid deallocation > costs: you just de-allocate the whole pool. > > 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 :] -- 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
