Oh, something else I just thought of that's not written down. We worked very hard to make the Judy code as portable and independent (of the OS) as possible. As I mentioned earlier, it only depends on malloc() and free(), endianness, and word size, but unfortunately it's ifdef'd for known platforms instead of just key attributes (endian, word size).
Now, the supported word sizes (32, 64) should be good enough for a very long time, ditto both types of endian. But also wired into the code is an assumption about the CPU cache line size. As I recall, this size is pivotal to the choice of data structures, although nothing actually directly DEPENDS on it (like a macro value), but whatever we chose was not universal to all modern CPUs. I recall that Doug rigorously designed for and tested on only the "most modern platforms". However, we knew that PC (x86) boxes had half of our design size (if I recall right), but there wasn't much to be done about that. So, hypothetically one could improve Judy (a little) by studying currently modern cache line sizes, then getting a deep understanding of the Judy data structures and their sizes and tradeoffs versus these numbers, and possibly revising if appropriate to either work smaller (unlikely to help), or take advantage of bigger ones. We spent a lot of time refining data structures against the known, most-common size (in our playpen) to minimize cache misses (line fills) while using every bit available for something if we could (such as maximizing immediate indexes). Cheers, Alan ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Judy-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/judy-devel
