On 10/01/2011, at 1:18 PM, Alan Silverstein wrote: >> More important to most people is not even performance: this is a very >> hard library to work on so most users including me could never >> actually fix a bug if one were found. > > Agreed. > >> So .. the question is, does it work. Full Stop. Forget "as well". >> Yeah, I'd like it to be as fast as Judy or even faster, but if there's >> a single bug my whole product is completely screwed because it relies >> utterly on Judy. > > But it's never had a bug after being released. Period. > > We tested the crap out of it. I've used it heavily myself, and was > never disappointed.
But that's the point: the "old Judy" is heavily tested and in use in a several applications. The "new code" is untested, so there's a big issue trusting it. However the new code is more readable, more modern, less macro heavy, and easier to build. > >> For example suppose you use Judies of Judies to represent strings. >> After 64 bytes, if the string hasn't run out, you just point at a new >> Judy array. But now to delete the top level array in C, without C++ >> destructors to automate it, or a garbage collector, is a nightmare >> because you have to scan the whole arrays recursively, deleting >> objects bottom up. > > Not if use let the JudyS*() wrappers take care of that for you? That was just a trivial example. And Judy's string stuff only works on NTBS, not strings with counted length. You can get counted lengths by roll your own Judy arrays of arrays: just round the string up to multiple of 8 bytes, use J1 to store the length and J2 for the first 8 bytes. If length > 8 then store a second array in the first. [I'm thing of a set of strings here]. Ok, so all this is easy, but how do yo remove a string from the set? You can't just remove the key, because that would leave the value (another Judy array) dangling. You have to make sure that second Judy array is empty first. Yeah, it's just a bottom up recursive descent, but then this is a trivial example. If you have a harder example where you're mapping stuff, you have to be careful the target is deleted. For example consider mapping to a C++ shared pointer, you have to invoke the destructor. Will it fit in 64 bits? If not you need to malloc a object for it and store that pointer instead. Easy to mess all those indirections up .. :) -- john skaller [email protected] ------------------------------------------------------------------------------ Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Judy-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/judy-devel
