On 2006-11-08, at 04:52 EST, Matthew Cloy wrote:
Hi,
Can anyone clarify the projected speed of Legals DHTML script
execution?
At the moment, a very simple loop is taking 20 times as long as
standard browser script, will this improve?
Will the creation of views be quicker in DHTML than at present in
flash? (We rely heavily on dynamic view creation and deletion and
this is our main performance issue at present)
I basically ran a simple speed test that looped 100000 times adding
1 to a test variable each iteration, wrapped in two "new Date()"
calls to measure the base speed.
In a plain HTML file with a script block it took 61ms on my
machine. (Running I.E 6).
In a swf7 OR swf8 compile under legals, this took 359ms.
In a DHTML compile under legals, this took a whopping 1219ms!
You can find the code below if you want to run the tests yourself,
but I'm wondering why this is? The script code looks as though it's
come out of the compiler intact and without any extra gubbins, so I
guess there must be something going on in an interval / in the
background that's slowing down it's execution?!
I know it's not the Date() calls or browser optimizations as the
execution speed of all 3 changes linearly with the number of
iterations.
---
The code for the HTML page (the script was copied from the compiled
output of the DHTML compile in legals)
<body>
<script>
t=(new Date())
test=2
for(i=0;i<100000;i++){
test++;
}
t2=(new Date())
total=t2.getTime()-t.getTime()
alert(total + " " + test);
</script>
</body>
---
The lzx code is:
<canvas> <text id="resultstext" text="Hello" resize="1">
</text>
<script> <![CDATA[
var t = new Date();
var test = 2;
var i;
for (i=0; i<100000; i++)
{
test++;
}
var t2 = new Date();
var total = (t2.getTime() - t.getTime());
resultstext.setText("Results! " + total + " " + test);
]]></script>
</canvas>
Thanks for your mail. Your results are indeed surprising. I would
have expected them to be identical for Legal's and HTML because as
you have observed, the Legal's compiler does not really do anything
special to Javascript. It pretty much passes it straight through to
the browser. (With some caveats. I won't go into detail here, but I
can if people are interested in knowing more.)
When I run your two tests, I get the opposite result. The HTML is
much 'slower' that the LZX.
There are a number of things that can explain this:
Your HTML script is not exactly the same as what the Legal's compiler
generates. Note that to give the LZX <script> tag expected semantics
(that it is executed in the lexical order that it appears in your
source, but is executed in the gobal environment) the compiler
transforms the body of your script to a function where the top-level
variables are re-written as global references. Finally, this
function will be invoked by the instantiator in the idle loop, in
order with the LZX code that lexically surrounds it. The idle loop
instantiation is what implements the `initstage` feature.
Most Javascript engines have a 'feature' where they will silently
terminate any script running in the idle loop that exceeds a certain
number of repeated backwards branches or exceeds a certain run time.
These limits are different from the foreground 'Script Running
Slowly' limits. It is possible that your long for loop is triggering
such a condition in the Legal's case and perturbing your measurement.
The code below is closer to what Legal's emits (save the running in
the idle loop). If I compare this to Legal's in FireFox (on a
2.33Ghz MacBook Pro), I get the same result (~70) either way. In IE
(on a 2.0 Ghz ThinkPad), I get the opposite results that you did.
Legal's reports ~500 and HTML reports ~1200. Firefox reports ~130
for Legal's and ~260 for HTML. I suspect the discrepancy here is a
result of the idle loop being terminated in Legal's, but perhaps
there is something else going on.
<body>
<script type="text/javascript" language="javascript 1.5">
<!--
_root=this;
(function () {
_root.t=void 0
_root.test=void 0
_root.i=void 0
_root.t2=void 0
_root.total=void 0
t=(new Date())
test=2
for(i=0;i<100000;i++){
test++
}
t2=(new Date())
total=t2.getTime()-t.getTime()
alert((("Results! "+total)+" ")+test)
})();
//-->
</script>
</body>
Note that the IE JScript engine has some known performance issues
(like being an order of magnitude slower than the Firefox engine!),
and that your simple measurement may be running afoul of garbage-
collection overhead, time-slicing, etc. If you want to make more
accurate performance benchmarks, you may want to look at the
[Performance](http://www.openlaszlo.org/lps/docs/guide/performance-
tuning.html) chapter in the documentation and use the performance
meters for measurement. The performance meters can be used to gather
data over a number of runs of a benchmark and they will record the
mean, variance, max and min values, which will give you a better idea
of how much confidence to have in your measurement. There are
examples of how to use the performance tools in test/performance.
But the bottom line is that there is no magic here. Legal's is (for
the most part) delivering javascript straight through to the
browsers, as you observe. So Legal's will be as efficient as the
browser is. If it is not, we have a bug we need to fix!
Finally: Ben is working on a whole benchmarking framework that will
let us easily track performance as the system changes. It is based
on the performance meters I mentioned above, but it has logging back
to the server so that benchmarks can easily be run automatically and
their results analyzed and tracked. We are not forgetting about
performance.
