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.
>> 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 .. :)