Use prototypes for the XUL content model to reduce cost of creating content model.

I hacked nsXULDocument so that when a second instance of the same document is "loaded" (e.g., bringing up a second navigator window), we share the content model instead of re-parsing all of the XUL, JS, and CSS files. On a optimized build, Win32 300Mhz i386, I saw the "open new browser window" drop from 790ms to 190ms.

Whoa! That's great news. I have this idea that uses xptcall and a [mutator] ([const,mutator] is legit and necessary in this scheme for certain methods) property in IDL files, to make a fairly generic copy-on-write proxy. Users would have to supply a copy method, which for a tree node would have to copy the ancestor line (arbitary digraphs would need to copy the whole graph, worst case -- is that an issue for content, or is it a tree, or nearly a tree?). Does this sound like a promising approach, or should we just "do it by hand"? /be

As far as having to execute scripts a second time, we might want a way to specify that a script doesn't require re-execution for subsequent windows (e.g. it just mutates the chrome in some appropriately-constant way).

Just checked in changes to nsXULElement to factor out heavyweight instance variables. Now working on pulling out code from SetAttribute() that will need to be made part of the delegate construction process.

Begin the home stretch for factoring content model construction. Create XUL_SHARING_19991022_BRANCH in mozilla/rdf.

'Hello, world' .xul now loads. Debugging more complicated XUL files.

I can bring up the bookmarks XUL file now. On to the navigator.xul and the other Big Dogs.

Roll work forward onto XUL_SHARING_19991027_BRANCH. Hyatt, I had to clobber your chrome registry stuff. It all needs to be redone anyway. Sorry.

Okay, I think that this is almost ready to land. I need to test on Unix and Mac, and do a commercial build, but Win32 is looking pretty good. Mailnews and addressbook are all cooking. Hyatt, should we get together and code review this again? Changes made today include... 1. do broadcaster hookup 2. deal with template builders that are on outermost overlay tags; e.g. <overlay> <tree datasources='rdf:foo' /> </overlay> 3. Fix heavyweight "faulting" when fault is caused by a SetAttribute().

I should say, "Phase II is ready to land", where Phase II is building a prototype content model, and then building the -real- content model from the prototype. Phase III is caching and brutally sharing those prototypes.

"Phase III" landed; XUL cache landed and turned on, controllable via pref. Brendan, I'm going to reassign this bug to you, close it out when you finish your JS sharing work.

Almost there -- waiting for shaver to review some all-in-one-place JS changes for auto-cloning of functions compiled in a prototype object but defined by their containing script's bytecode prolog in various delegating objects. Already have waterson's review of XULDOMJS_19991106_BRANCH changes under rdf. /be

I'm done with script sharing via waterson's XUL prototype elements. Sharing of compiled event handlers via prototypes I'm gonna do as part of 13218, which asks for lazy compilation of event handlers (an even bigger win for first window), so I'm closing this one. Someone reopen if quantify says things arent better, or reopen now and self-assign for qfy-verification. /be

BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL. XUL component will be deleted.