> 88 declared but unused variables
> 47 declarations of the same or similar variables
> 427 instances of "else if" instead of "elsif"
> 100 instances of I = I + 1 instead of i+=1
> Numerous examples of variables declared inside for loops, and some of those
> are inside other for loops
> Variables declared inside condition statements.
So, just to get this out of the way, some benchmark tests. As you have probably
discovered by now, elseif isn't valid syntax and leads to a parse error, so my
427 instances of using it are trivial to justify :-)
Execution time of various code snippets:
===========
for (var i = 0; i< 10000000; i=i+1)
takes 2.3 seconds or 0.00023 ms per iteration. The loop structure itself, even
if you run it up to 1000 iterations inside a frame, delays the frame only by
0.23 ms.
===========
for (var i = 0; i< 10000000; i=i+1)
{
var testvar = 1.0;
}
takes 3.0 sec, i.e. the extra time to assign a variable inside the loop is
0.0003 ms.
===========
var testvar = 1.0;
for (var i = 0; i< 100000000; i=i+1)
{
testvar = 1.0;
}
takes 3.1 sec, i.e. declaring a variable outside the loop isn't actually any
faster, it boils down to practically the same time.
===========
for (var i = 0; i< 10000000; i=i+1)
{
var testvar = getprop("position/latitude-deg");
}
shows that property tree interaction is an expensive operation - this takes 11
sec, i.e. the extra time to pull something from the tree is 0.00087 ms per
operation. However, even having 1000 of these per frame delays the frame just
by 0.87 ms.
===========
for (var i = 0; i< 10000000; i=i+1)
{
var testvar = math.sin(i * 0.2);
}
executes in 16 sec, showing that trigonometry is about the same order of
expense as interacting with the property tree, i.e. having 1000 trigonometric
operations per frame delays you by 1.37 ms.
===========
var info = {};
for (var i = 0; i< 10000000; i=i+1)
{
info = geodinfo(lat, lon);
}
Now for comparison where the real stuff is happening - this takes a whopping
350 sec to execute, i.e. executing even just 100 geodinfo() calls per frame
would delay you already by 3.4 ms. Even worse, the execution speed of
geodinfo() depends on terrain detail, the case study is TNCM where most of the
terrain is ocean, in custom scenery geodinfo can easily take much longer (for
Grenoble LFLG I get 1100 sec), i.e. a single call in custom scenery is already
about 0.1 ms of frame delay.
Oh well, and it used to be even 50 times slower than what we have now ;-)
===========
This might give you some idea why optimizing the code makes only sense in some
areas - whatever you do with the Nasal-internal stuff, it's never going to come
even close to what you gain by avoiding even a single geodinfo() call. Advanced
Weather doesn't burn any significant performance inside Nasal - it burns the
performance by calling hard-coded C++ functionality from Nasal.
Cheers,
* Thorsten
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
