See the 120 or so lines of code starting at http://lxr.mozilla.org/seamonkey/source/content/xbl/0 bsmedberg, do you think that changing the relevant hashtables to nsInterfaceHashtable will be a win in either speed or codesize? It should certainly be a win in code clarity... In any case, this depends on bug 224765, since I'm touching code in that general area in that patch...
converting from doublehashtable is a good thing... it's deprecated and not really being maintained. This will almost certainly help codesize a bit, perf will probably stay flat. --BDS
Note that the nsDoubleHashtable instances are being removed in bug 224765. This bug is about the remaining raw PLDHashTable instances (http://lxr.mozilla.org/seamonkey/source/content/xbl/0).
oh, well then... I think if it works and there aren't obvious problems, don't mess with it... raw pldhash code is going to be a little bit smaller than template code.
Well, this code has a bunch of methods to make the PLDHash code more palatable... if the codesize changes are not going to be too big, I would like to aim at reducing complexity. So as long as it's same ballpark, I'll whip up a patch and see what effect it has.
Priority: -- → P1
Target Milestone: --- → mozilla1.7alpha
OK, I just tried this. The codesize difference is about 20k unstripped, 12k stripped (with the template code bigger). Looks like each template instantiation is about 5k, which adds up... :( If I make all the hashtables nsISupports -> nsISupports, then I get something more like 4k increase, but at that point it's not worth it -- I have to cast and shit anyway. I guess there's not much we can do to shrink the size of nsInterfaceHashtable, right? Wontfixing, since the extra 12k really aren't worth the (rather minimal, really) code clarity improvement.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.