Re: nsGenericElement::InsertBefore performance

Boris Zbarsky wrote:
> Andreas Pflug wrote:
>   
>> 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....  (...)
>   
Well I'm aware that it's NOT like adding an item to a listbox. If I had 
to implement this in w32 or some gui dev lib, I'd probably create an 
owner drawn item, which itself has a few sibling controls. 
Initialisation will still be several magnitudes faster, since all 
controls will use their readily compiled handlers.

I see the problem that XUL/XBL is used as if it was as cheap as it is 
with typical gui lib, not as expensive as preparing a DOM for rendering 
lots of interactive stuff in a frame. XUL/XBL is intended to do typical 
application programming (I think?), but using typical programming 
techniques will lead to poor results (unfortunately demonstrated by 
Sunbird/Lightning, which appears as some kind of Mozilla demo app to me 
since it's integrated into the mozilla source tree).
>
>
>   
>> That's why I've been suggesting caching techniques beyond XBL 
>> caching.
>>     
>
> Caching what, exactly?
>   
A partial DOM. So instead of adding a bunch of nodes (which all need a 
lot of basic initialisation), in a first step a partial tree of those 
nodes is instantiated, not attached to the DOM (although probably 
somewhat "prepared" for a specific document), and held in a caching 
area. Then when adding the xxxx-item a "cache using" node that will be 
added to the DOM, consisting of a reference to the cached node tree, and 
some individual data (e.g. label text).  Easy, no? ;-)

>   
>> 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.
>   
(Not "my" source, BTW, I'm just a guy who wants to use Sunbird :-)
I'm in doubt that stripping down the DOM to the minimum will be 
sufficient. I don't have the XBL experience to check this, or decide the 
chance for successful reduction. There are a few suggestions on the 
calendar list, I wonder how this should happen efficiently without 
sacrificing functionality.

Actually, I don't quite understand your comment above. Do you say that 
it's quite a lot of XBL-bound DOM stuff (that should be reduced), but it 
will only be cloned if attached again and again? In this case, cloning 
seems a) still much too costly and could b) be optimized if the partial 
item's DOM isn't cloned (each cal-mon-day-item uses about 20k) but only 
references a "template" DOM.


I'm sorry that I can't make any concrete ideas, I'd have to read and 
trace the sources for many hours to understand what's really going on, 
so all I can do is trying to evoke some half-brewn ideas.

Regards, Andreas