Thank you for taking the time to put together such a detailed response!
WRT the silent termination of idle functions... I would expect that to
cause a "cap" in the timing, but I tried the new code you sent and that
runs in 78ms,and if I up the loop counter 10x to 1000000 the timing is
765ms (10x as expected), so I doubt the loop is actually being aborted
in the HTML case.... I need to restart to continue testing, so I will
continue benchmarking using the performance meters and see whether I can
make more sense of the figures I'm seeing. I'll also look at
benchmarking under different machines and different browsers as I only
tested IE... I Will let you know the results and methodology, if that
would be helpful?
The basic advantages I'm looking to gain from legals HTML over what we
had before are:
1) Ability to use "eval" to evaluate scripts passed via XML (We are
building our view hierarchy entirely at run time, as we can't run the
servlet... for simple scripting I have implemented a basic "javascript"
compiler / interpreter in laszlo script. not the fastest solution but
good enough for "onclick"->open something type scripts)
2) Ability to embed browser plugins INSIDE laszlo views. (We have a
windowing / UI system in laszlo, and a number of custom browser plugins
for displaying data, and at the moment we float the plugins as an IFrame
over/under the flash plugin.. which is rather ugly..)
Do these two goals sound achievable to you?
Thanks again!
Matt.
P T Withington wrote:
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.
