This is just a heads-up about bug 96108 (inlining nsVoidArray::ElementAt()).

The outcome of the patch will be (among other things) to change ElementAt()
to no longer bounds-check the index.  Currently the index is checked for
negative and past-end values and returns nsnull in those cases.  I do plan
to add an ElementAtBoundsChecked() (or some such) for code that doesn't
want to do this itself.  The [] operator will use the unchecked version.
Note that NS_ASSERTION()s will remain in place for both cases to help avoid
bugs in indexing slipping into production code.  This initial release may
still return nsnull (and assert) for past-end references until we're sure
all of them have been handled.

The patch includes changes to many files in the tree to remove these sorts
of dependencies.  For now (at least), nsGeneric[HTML]Element::ChildAt()
will check for past-end indexes and return nsnull (to avoid a lot of
rewriting).  Several extant bugs were found in users of ElementAt along the
way and fixed.

This is expected to produce 1-2% pageload improvements because of the
extensive use of ElementAt(), with minimal to no code bloat.

Also, as part of bug 100231, we're moving nsCheapVoidArray from content
into xpcom as nsSmallVoidArray.  This is a somewhat special-purpose 
wrapper-class for nsVoidArray, meant for cases where a) the values are
always even ((array[i] & 1) == 0 i.e. allocated pointers), b) space is at
an absolute premium, and c) the expected distribution of array sizes is
heavily slanted to 0 and 1.  As part of the move, nsSmallVoidArray will
support the entire range of nsVoidArray methods now (an nsAVoidArray may
someday make sense, or might have in (years of) hindsight).

-- 
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team
[EMAIL PROTECTED]
"They that can give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety." 
              -Benjamin Franklin, Historical Review of Pennsylvania, 1759.

Reply via email to