On 10/01/2011, at 9:20 AM, Alan Silverstein wrote: > With some > creative variations in the API. Does it work as well? That's the key > criterium to me.
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. 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. > The introduction could but does not say why libJudy is special. In my > mind it has to do with the iron-clad by-expanse (radix) approach to > decoding keys (indexes), which is infinitely extensible, FYI: this is not quite true. Technically yes. But in practice no, because of the old "memory management problem". It's fine to glue arrays together, but it's very hard to ensure correct memory management in the presence of variants other than NULL. 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. Of course if there is any sharing at all, then it is almost unmanageable. -- 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
