Closed Bug 224850 Opened 21 years ago Closed 21 years ago

nsBindingManager uses PLDHash where maybe it should use nsInterfaceHashtable


(Core :: XBL, defect, P1)






(Reporter: bzbarsky, Assigned: bzbarsky)



See the 120 or so lines of code starting at

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.

Note that the nsDoubleHashtable instances are being removed in bug 224765.  This
bug is about the remaining raw PLDHashTable instances
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,

Wontfixing, since the extra 12k really aren't worth the (rather minimal, really)
code clarity improvement.
Closed: 21 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.