John etc, > You shouldn't underestimate how much more exposure and influence the > project has now that it is open sourced. Besides the programs out > there that link against libjudy, there are probably dozen of radix > tree implementations out there than were inspired by reading about > judys implementation.
WOW! That's good to hear. It appeared to me, at least, that just a few people, a handful in the whole world, even noticed the package. (But I'm not Doug, managing the SourceForge site and tracking downloads, so I don't know.) > The heap compression techniques I use in my jhc compiler were heavily > influenced by your work on judy and in particular your attention to > cache line loads. Cool! I suspect this was based more on reading my "Shop Manual" (wish I'd found a better name than that, and written it in HTML not Framemaker), rather than the source code? :-) > ...I could sweep just by discarding the judy tree and not having to > traverse the whole heap looking for free bits helped allocation time a > lot. Yeah, that kind of usage, what I call "synergistic serendipity" or if you prefer, "serendipitous synergy," is what Doug, and later I, got excited about with libJudy. We used to imagine, "what could you do with a dynamic sparse array if it was really cheap and fast?" We found all kinds of interesting applications, but in most cases using libJudy required some unusual thinking at best, warped at worst. We spent some time during the project looking for "killer apps" to demonstrate the value of the library... But it was surprisingly hard. Basically you had to have libJudy in your toolbox during project design and implementation. It was very difficult to retrofit afterwards to significant tools. Quite often 80% of the same benefit could be had just by tweaking some hashing constants that had gotten dusty. > autoconf is great... But as later emails to the group stated, even that's debatable. :-) Anyway as De Marco observed, "people optimize whatever is measured, and hide their garbage elsewhere." Despite knowing this, and trying to cover ALL the bases, it's obvious in hindsight that what we created had various shortcomings, garbage where we didn't "measure" closely enough. Most of our project's effort went into version 4 (Judy IV), the final version, which took a lot longer than expected; core coding and documentation efforts. We were focused on HPUX (after all HP was paying the bills), which didn't even have C explicit inline functions at that time. So open source portability suffered, and in hindsight, documentation and code readability too. > I always assumed the odd API was to conform to some internal HP coding > standard created by someone who has a history with algol (hence the > in/out arguments) I've seen odder ones forced on programmers out > there. No, actually it's kind of funny in a sad way. I was always a very persnickety UI and manual entry designer. I wrote a lot of Unix commands and documentation over the years, both for the HPUX product and for "toys," so I was very good at this. For libJudy I came up with some very solid (I thought) manual entries. But Doug really wanted to simplify the API; hence the macro API. Later he had a manual writer essentially throw away half of my documentation work (without telling me first) to make the macro API the main entry point, and the formal signatures and related description (whatever remained) an afterthought. In the long light of time, I think Doug was wrong, and I deserve an "I told you so" about that change. The macro API has confused people more than Doug ever intended, and made it even harder to code properly too. It seems to me that only "real experts" (who can handle the raw truth, even prefer it) end up seriously using libJudy. But conversely, another common gripe about libJudy is how the source code is painfully abstract to read. Yeah, a dynamic sparse array is already a difficult (abstract) notion with poor real-world metaphors. Being aware of various UI principles like, "one object for each name, one name for each object," I drove Doug nuts insisting that we think very carefully about what to call everything, aiming for clarity, precision, "psychological distinction", etc. (Sorry Doug, resistor-colored "flowers" as the leaves in the tree were cute but confusing!) But I yielded on the name of the library itself (Judy), which I now regret because it's "weird" and turns some people off. Maybe we should have just gone with an acronym after all. But what? An early version, first time I heard of Doug's little project, used it myself, and got excited, was called SAMM = sparse array memory manager, but libJudy grew well beyond that first concept. Anyway since we needed very tight control over the C code, but didn't have inline functions, and being comfortable myself with C macros, even fairly hairy ones where you pass as a parameter the name of another macro, I tried to build minimal-redundancy code that would be as clear and fast as possible. In hindsight though, the excessively abstract macros themselves threw most people, no matter how much I tried to find good object names and document everything carefully. Maybe Doug was right, and it was better to just repeat nearly identical code sections 7-8 times rather than "compressing" the source with levels of macros. > ...my background is in embedded programming/operating systems and > performance programmimng, I never got over the habit of examining the > assembly output of every code change... Good. :-) We did that a lot. Cheers, Alan Silverstein ------------------------------------------------------------------------------ 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
