the advantage: pldhash allocates all its entries in one large buffer, that is shared with the rest of the hashtable data. Because all the entries are stored in one block, the only allocator overhead is per-table, rather than per-entry. When the buffer gets full, it moves the entry to a new, larger block. In addition, the entries can be any size, which means you can store your "value" data in the entry, in addition to the key.
As I commented in the bug, I think string ownership is fairly well defined by nsStringKey's ownership flag. At least, it allows you to prevent nsStringKey from making copies of its string data when you know that the string will continue to be owned.
Personally I think that the real thing to go after is to find a smart way to arena-allocate the hashkeys, but I think that is a hard problem, since technically the keys can be of any type. However, arena-allocating strings isn't quite so crazy and could be done without much trouble.
Alec
Benjamin Smedberg wrote:
What are the functional differences between nspr/lib/ds/plhash.h and xpcom/ds/pldhash.h. Is pldhash.h newer and more-efficient than plhash.h?
I have been completing a template-based hashtable for C++ objects based on plhash.h, because I found it first (similar to nsObjectHashtable, but automatically threadsafe). I have mostly gotten the code working... would it be worthwhile to think about recoding using pldhash.h instead?
I also see bug 119745, regarding nsStringKey. how often is nsStringKey actually used? Would it make sense to optimize nsStringKey to use shared buffers a la nsSharableString, to reduce memory usage? If there are many nsStringKey objects floating around, I would think you could obtain a sizable memory reduction, and reduce fragmentation on the heap. I just filed http://bugzilla.mozilla.org/show_bug.cgi?id=180264 on that issue.
