Re: Revisiting IndexOf

Smaug wrote:
> On 6/22/09 4:54 PM, Boris Zbarsky wrote:
>> I was looking at some profiles recently that happened to spend a lot of
>> time in IndexOf because they thrashed our IndexOf cache.
> Bug numbers?

https://bugzilla.mozilla.org/show_bug.cgi?id=440641 comes to mind.

> The setup doesn't sound too complicated, but would be great to
> have some worst-case-tests and also best-case-tests -
> at least to see where the time is spent currently and where with the
> approach.

Yeah, indeed.  I'm not quite sure what he worst-case for my proposal is 
yet; that depends on the details of the renumbering algorithm.

I guess the question I have is whether this is worth pursuing at all (as 
in, whether we're willing to add a double member to nsINode).

> (I wish someone would make also nsIFrame tree handling fast, especially
>  getting the last child - that shows up in the profiles pretty often.)

https://bugzilla.mozilla.org/show_bug.cgi?id=233463 if you care...  It's 
hard to do because all sorts of code assumes that frames are a 
singly-linked list with the owner holding a pointer to the first node 
and does manual surgery on this list.  If we actually used the 
nsFrameList abstraction throughout when dealing with a frame list, that 
would make it much easier to make the last frame fast; the changes would 
be localized to nsFrameList.

It would probably also make it easier to do other changes to the way we 
store frames...  So if someone wants to pick it up, that would be great.

-Boris