3 ms·
From 2004. I've always felt suspicious towards this package. It's a huge amount of code to squeeze a little bit of extra performance out of an otherwise simpl
by throwaway81523 4y ago
From 2004. I've always felt suspicious towards this package. It's a huge amount of code to squeeze a little bit of extra performance out of an otherwise simple operation. I don't know if it used much any more. I figure if the standard modules aren't fast enough, maybe it's better to tailor something to the application, than use a heavily optimized but very complicated general purpose library.
- 314 4y agoThe key claim is that it has been specialized against the target architecture to tune each parameter optimally. But, yeah that was done 20 years ago and it is not clear how much the costs have shifted on modern architectures.
- lifthrasiir 4y agoEven at that time the claim was heavily challenged [1], and I agree to Sean's conclusion: Judy array might be slightly faster for some applications but an added complexity is not worth it. [1] https://nothings.org/computer/judy/ https://nothings.org/computer/judy/ (2003)
- vanderZwan 4y agoOn that note, it's interesting to me that the wiki page for Judy arrays mentions that the "smallest implementations are thousands of lines of code", but then also links to a 1250 LOC implementation in the references. The latter might be a more interesting jump-off point for experimentation than this massive library. [0] https://en.wikipedia.org/wiki/Judy_array https://en.wikipedia.org/wiki/Judy_array [1] https://code.google.com/archive/p/judyarray/ https://code.google.com/archive/p/judyarray/ [2] https://github.com/JanX2/judy-arrays https://github.com/JanX2/judy-arrays (github export of previous)