Re: [Flightgear-devel] Efficient Nasal coding (was: Stuttering at 1 Hz rate)
On 30.03.2011 08:31, thorsten.i.r...@jyu.fi wrote:
How do arrays and objects count? If an object counts as one reference,
then it's very efficient to use I guess - if every key in the hash counts
as one, then certainly less so.
Right. I believe arrays and hashs may both be implemented efficiently - so
may count as one Nasal object only. But I haven't looked into the details of
the Nasal engine itself - I just checked the discussed performance issues
and briefly looked at the garbage collector. I'm sure Andy would know all
the tricks and details, of how efficient specific constructs are :).
Can loops pile up garbage checks only for elements referenced
(theoretically) within the loop (regardless if they are actually
executed), or do they trigger the whole possible pile of Nasal to be
searched? So if someone fixes a badly written script which runs every
frame although it really doesn't need to - will that affect the load
generated by that particular script, or will it have a more general
effect?
Garbage collection is a global thing and cannot be restricted to a local
context. It always requires a complete search. Even if usless handlers are
executing, eventually their repeated execution will also trigger the garbage
collector, which then needs to recurse through all references. The load
(delay) caused by the garbage collector will hit a random Nasal line, which
happened to be running out of certain resources. Again, Andy would
probably know the details of what exactly the conditions for triggering the
garbage collector are, and what kind of operations consume these resources -
so make the g/c happen more often.
However, I have attached a simple patch which I used to generate the
statistics. So, if you're interested in optimizing the performance of your
module, apply this locally and see how the numbers and the g/c frequency are
influenced by specific changes. You'll see how many unique objects were
found, how many references had to be searched (which is what consumes most
of the time, since every reference has to be traversed), and of course
when/how often the garbage collector runs.
cheers,
Thorsten
diff --git a/simgear/nasal/gc.c b/simgear/nasal/gc.c
--- a/simgear/nasal/gc.c
+++ b/simgear/nasal/gc.c
@@ -1,9 +1,16 @@
+#define NASAL_GC_STATISTICS
+
#include nasal.h
#include data.h
#include code.h
#define MIN_BLOCK_SIZE 32
+#ifdef NASAL_GC_STATISTICS
+static int g_ObjectCount = 0;
+static int g_RefCount = 0;
+#endif
+
static void reap(struct naPool* p);
static void mark(naRef r);
@@ -37,6 +44,11 @@ static void garbageCollect()
{
int i;
struct Context* c;
+#ifdef NASAL_GC_STATISTICS
+g_ObjectCount = 0;
+g_RefCount = 0;
+#endif
+
globals-allocCount = 0;
c = globals-allContexts;
while(c) {
@@ -74,6 +86,11 @@ static void garbageCollect()
globals-deadBlocks = naAlloc(sizeof(void*) * globals-deadsz);
}
globals-needGC = 0;
+
+#ifdef NASAL_GC_STATISTICS
+printf( Nasal garbage collection statistics: objects: %u, references: %u\n,
+g_ObjectCount,g_RefCount);
+#endif
}
void naModLock()
@@ -226,11 +243,21 @@ static void mark(naRef r)
{
int i;
+#ifdef NASAL_GC_STATISTICS
+// count every traversed reference
+g_RefCount++;
+#endif
+
if(IS_NUM(r) || IS_NIL(r))
return;
if(PTR(r).obj-mark == 1)
return;
+
+#ifdef NASAL_GC_STATISTICS
+// count unique objects
+g_ObjectCount++;
+#endif
PTR(r).obj-mark = 1;
switch(PTR(r).obj-type) {
--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Efficient Nasal coding (was: Stuttering at 1 Hz rate)
On 03/29/2011 11:31 PM, thorsten.i.r...@jyu.fi wrote:
for (var i =0; i 30; i=i+1) # number of objects is 30
is superior to
var number_of_objects = 30;
for (var i = 0; i number_of_objects; i = i+1)
No it isn't. Variable references aren't garbage (well, they aren't
heap blocks, though they do get traced). The things they point to are
garbage, and a number isn't a reference in Nasal. The 30 in the
second example gets stored (as a double) directly in the hash record
in place of the pointer that would be there if it were a reference.
The var syntax has no meaning as far as allocation. It's about scoping,
it says make this a local variable in the current function no matter what
outer scope it might also be in.
The operations in Nasal that create heap blocks/garbage are:
1. String composition with the . operator
2. Vector creation with a [...] expression
3. Hash creation with a {...} expression
4. Function calls (which create a hash for the namespace)
5. Closure binding with a func ... expression.
I believe that's all of it, though I may have forgotten something.
Andy
--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Efficient Nasal coding (was: Stuttering at 1 Hz rate)
And since something like don't complain, just do it was mentioned:
I'm not complaining (my new machine is doing fine for now). I've just
analyzed it and mention the facts.
Yes, actually your post is quite the opposite of complaining - it's very
informative and constructive in that it suggests how to improve things.
So, if I may ask a few question if I understand it correctly:
1. The length of the delay depends on the number of references the
garbage collector needs to traverse: variables (data), but also
functions, which are just like variables in Nasal, e.g.
var myVariable = 42;
var myFunction = func()...
It doesn't depend on the size of a particular function or basic
variable though.
To put a bit simplistic, it counts how often I used 'var' in the code.
That seems to make a case for somewhat ugly coding style, in that
for (var i =0; i 30; i=i+1) # number of objects is 30
{
compute_stuff(getprop(some-property),i);
}
is superior to
var number_of_objects = 30;
for (var i = 0; i number_of_objects; i = i+1)
{
var some_property = getprop(some-property);
compute_stuff(some_property,i);
}
since the latter bit of code uses two more variables. (I'm tempted to say
'told you so' to a certain person...). Also I guess more dangerous things
like replacing local loop variables by a few global ones (provided you
don't run into nested loops...) would theoretically help then?
How do arrays and objects count? If an object counts as one reference,
then it's very efficient to use I guess - if every key in the hash counts
as one, then certainly less so.
2) The g/c frequency mainly depends on how much stuff is done in
Nasal, including the number of timers and the timer frequencies.
I understand the basic principle 'if you don't need it, don't run the
loop, if you don't need it every frame, then don't run it every frame'.
But I'm not sure just how the load is generated.
Can loops pile up garbage checks only for elements referenced
(theoretically) within the loop (regardless if they are actually
executed), or do they trigger the whole possible pile of Nasal to be
searched? So if someone fixes a badly written script which runs every
frame although it really doesn't need to - will that affect the load
generated by that particular script, or will it have a more general
effect?
Thanks,
* Thorsten
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
