Daniel Veditz wrote:
> Brendan Eich wrote:
>
>>> It doesn't count the time spent opening and compiling each .js file which
>>> seems to be a major drawback (would we speed things up by combining .js
>>> files? Can't tell). Any idea where a good place to add a hook for that would
>>> be?
>>
>> FYI, XUL JS is compiled at load time (startup or first new window for a
>> given XUL application), and never recompiled. So for profiling
>> operations such as deleting 30 selected mail messages, compile time is 0.
>
> True, but one of our sore points is sluggishness opening new chrome windows
> and dialogs -- compile time might be a factor there. Or maybe not, and then
> we'd have numbers to prove it to each new person who comes up with the
> bright idea that js compile time is part of the problem.
We went through this in late '99, and the result was a fairly aggressive
optimization called "brutal sharing". The XUL document and content code
keeps a prototype tree for each kind of chrome window, which can be
quickly cloned, with copy-on-write for elements that vary after you make
a second, etc., window of a given type. All scripts and event handlers
are compiled for the first window, and only executed thereafter.
I forget the quantify breakdown after we were done, but it should be
archived in m.porkjockeys. JS compile time didn't dominate the critical
path to first-new-window-of-a-given-type, in any event, although with
heavier use of JS in newer content, possibly it could. Cc'ing waterson
in case he remembers, or has new numbers (but he's not the only one who
can run quantify!).
Which reminds me: time spent in the JS compiler is time spent executing
native code, not time spent interpreting JS bytecodes, so good ol'
quantify is the right tool to use when profiling. There is no need to
extend the JS (XPConnect) profiler.
<whine>I wish more people would run a hierarchical profiler before
coming up with guesses about where cycles go.</whine>
/be
