> I don't know what is the eternity problem with judy-interface...
Thanks, it's nice to hear that for a change. :-)
> I think it is not a good idea to use the macro interface as
> recommended in the docs (it's not faster)...
Actually buried in the macros there is a LITTLE performance boost for
small arrays; see Judy.h. I'd forgotten it was even there. But in
general you are right.
I'm now making major use of libJudy in a contract job, with their
blessings. I chose to use the macros to keep it short, simple, and
palatable as possible. But, as I've written before, even I get lost in
the abstractions at times, when I have array-of-array, etc, and must
think carefully, or fix the code. Plus I end up having to do strange
things like this to make it happy:
JSLI(valuep, arrayp, index1);
PPvoid_t subpp = valuep;
JSLI(valuep, *subpp, index2);
...
The macro actually does (&*subpp). But you gotta get the typecast
right, also for indexes in some cases. Using functions would be more
verbose, but more explicit, and also the for/next loops to walk arrays
would be tidier.
> The only drawbacks i found in judy:
> - you cannot store more than sizeof(*pval) as value in the array.
> You must use the pval indirectly (storing the pointer).
Yes, although this falls directly out of libJudy being honed for
performance for what it does best, as a low-level engine. Somewhere in
the docs is discussion of a potential API we talked about a lot, called
"Judy-star" (as in Judy*()), along the lines of, JudyL()'s values are
long-words, etc.
On one hand, you can argue that there's no net performance gain by doing
this. For example, to free() an array, you still must walk all the
members first to free() their (non-Judy) substructures. My new code
using libJudy has this, for example, JudySL -> JudySL -> struct, and I
must free() each struct myself.
On the other hand, if libJudy itself had a built-in concept of "variable
size value", it MIGHT be faster, as well as simpler for the coder. Then
the libJudy insert, delete, and free routines would manage the memory
for you, and locality of operations would be maximized. But would you
have it return a valuep, and the caller still copies their data into the
value area after the Judy insertion call returns, or would you have the
caller pass a pointer to the record-to-save itself, and have Judy do the
copying? Etc.
Anyway, the project (at HP) was canceled before we got into this kind of
enhancement.
> - The JudyNext and JudyPrev can be improved in speed, by using a
> current cursor-structure as parameter.
What does that mean? They are already very fast because the next
iteration starts with the previous index, and the libJudy nodes are
almost always in the CPU cache, ready to go.
Thanks,
Alan Silverstein
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Judy-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/judy-devel
