Re: nsGenericElement::InsertBefore performance

Andreas Pflug wrote:
> Still, playing devil's advocate, I'm wondering if optimizing CSS rules 
> will be enough

Of course not.  It's a minor side-show.  What needs to happen is to simplify the 
chunk of DOM you're adding.

> To me, the problem 
> seems fundamental, in the sense that typical application programming 
> technique (adding an item to a listbox is a microsecond action)

I really wonder where you got the idea that you're adding an item to a 
listbox....  XUL supports listboxes, and you can time adding items to them if 
you want.  I don't know that it'll be a microsecond action, but it'll be a lot 
faster than what you're doing.

What you're doing is closer to creating an entire groupbox with a bunch of 
controls in it and then adding it to a dialog.  That's the sort of timing you 
should be comparing to.  It might not be what you _want_ to be doing, but it's 
what you _are_ doing.  Just look carefully at the stuff you're sticking in with 
this single insertBefore call:

   10 grouping boxes
   8 images
   2 labels
   1 text control
   1 spacer

That's assuming that the only node inserted by "calendar-month-day-box-item" 
which has a binding of its own is the textbox.  If there are others, then there 
will be more stuff in there.  In addition to adding all these controls, you're 
running various initialization script and so on.

> resulting in deep CSS interpretation again 
> and again.

The CSS is not the major problem.  The fact that you're tossing at least 20-some 
nodes into the DOM is the problem...

> That's why I've been suggesting caching techniques beyond XBL 
> caching.

Caching what, exactly?

> All calendar-month-day-box-item have limited individual 
> property variations, and could reuse the same set of "compiled" 
> definitions

XBL-attached JS is cached in a "compiled" state.  XBL-attached DOM is stored as 
a DOM which is cloned (much faster than parsing) when attached.  The real issue, 
again, is that your binding has too much stuff in it.

If you have concrete ideas of how this could be faster, I'm all ears, but my 
instinct if I personally were optimizing this would be to start with eliminating 
a lot of that XBL-bound DOM.

-Boris