Re: nsGenericElement::InsertBefore performance

Andreas Pflug wrote:
> Well with a .mozconfig of

I know how to build calendar.  Though I should note that once you --enable-debug 
and --disable-optimize your performance numbers are meaningless: you're talking 
different algorithmic complexity in a lot of cases.

>>   If sunbird is the only way to reproduce, you need _much_ more clear 
>> instructions to reproduce (click-by-click instructions).
>>   
> Select month calendar view, create one simple event, then click the 
> calendar's checkbox on the left side to "off", start profiler, click 
> calendar on, stop profiler.

Maybe I wasn't clear....  I don't want a high-level description of the task.  I 
want detailed steps.

Let me illustrate.  Say you wanted to increase the font size on all 
Chinese-language web pages in Firefox.  I could tell you "Go into preferences 
and increase the Chinese font size".  That would be a high-level description, 
and is completely useless for someone unfamiliar with the application.  The 
right description is (on Windows, iirc):

1) Start Firefox
2) Open the "Tools" menu
3) Select the "Options..." option from this menu to open the
    preferences window.
4) In the top icon bar in the resulting window,
    click the icon labeled "Content".
5) In the bottom part of the window, find the "Advanced..." button
    in the "Fonts & Colors" section and click it to open the
     fonts dialog.
6) In the resulting dialog, select "Simplified Chinese" from
    the "Fonts for:" dropdown near the top.
7) Change the "Size" dropdown immediately to the right of the
    "Proportional:" dropdown to show a "20" instead of a "16".
8) Click "OK" in the fonts dialog.
9) Click "Close" in the preferences window.

> Yes, the VS2008 team edition, I don't have it.

I have a hard time believing there is only one profiler on Windows.

>   var box=document.createElementNS("...", "calendar-month-day-box-item");

You do realize that this has an XBL binding attached?  With at least 20 nodes, 
multiple images, a constructor that mutates the DOM (in ways that look 
unnecessary to me), and various other bells and whistles that are pretty much 
guaranteed to make things slow?

I'd need profile data with stacks to prove this, but I would be willing to bet 
just based on your function list that most of the time is spent instantiating 
the binding and executing all that javascript, DOM manipulation, etc.

> So actually the same initialization stuff is repeated all over again. I 
> wonder if some kind of caching mechanism could be invented:

XBL has such a caching mechanism.  That's the only reason that things aren't 
even worse than they already are in this case.

You _might_ be able to make things a little faster by inserting all the items 
into a single box that you then add to the DOM as a single operation.  But you 
might not.  The real fix here is to make the XBL less heavy.  Inserting tens of 
thousands of nodes into the DOM can only get so fast...

-Boris


-Boris