> Not sure exactly what you mean, but you can always take an arbitrary N
> bytes of anything, including embedded 0 bytes, and translate it to a
> UTF-8 NULL terminated string.

Good point.  I'm well-acquainted with base-64 encoding for example.
Just never thought of "safe reversible encoding to a null-terminated
string" as a practical solution for arbitrary key-to-value mappings...
Didn't start seeing base-64 until some years later...  Clever.

So you CAN use JudySL today, if you like, with a translator front-end,
to store any keys at all, can't you?

I wonder how it performs (both space and time) in real life?  For
example, people who understand hashing in some detail often work very
hard on improving their hashing algorithms to optimize the hash table,
what I call a "good spectral property" that keeps the distribution
random (although still usually key-distribution sensitive) and the
synonym chains short.  However unless they measure, they don't realize
that they ruined performance by spending way too much CPU time on the
hashing.

> Then you can use JudySL just fine, and the proper sort order is
> preserved because that's a property of UTF-8 encoding.

Interesting too, makes sense.

Bearing in mind of course that "sorting" itself is a rich and variable
concept, witness all the choices in sort(1).  Simple lexicographical
sorting is the baseline, and all libJudy gives you for free (since it's
a radix tree).

Cheers,
Alan

------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
Judy-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/judy-devel

Reply via email to