On Wed, 12 Nov 2008, Phil Barnett wrote:

Hi Phil,

> The difference is likely to be more pronounced when there are hundreds of 
> variables that are public, vs hundreds of locals scattered throughout the 
> software.

Neither in Clipper nor in [x]Harbour the speed of memvar variables
does not depend on number of allocated variables so it will not change
the result at all. Memvars variables in normal code are not accessed
by name. It's a mit which comes from Clipper days. Maybe some old Clipper
version make it. When .prg module is registered to each symbol item used
by memvar variable is assigned index to variable holder and then this
index is used in source code. It means that it does not make any symbol
table scans during evaluation and the speed is comparable to static and
local variables.

> Perhaps the test could be modified to show this problem of many publics.

As I said it will not change the results because memvars are not accessed
by name during PCODE evaluation. The only one place where they are accessed
by name is using memvars inside macro compiler during macrocompilation
phase, f.e.:
   x := &"{|| M->VAR }"  // here VAR is located by name in symbol table
                         // just like any other symbols, .f.e. function
                         // names.
   eval( x )             // no symbol scan during evaluation.

> Anyway that's how it was with Clipper. Not sure of Harbour.

I do not know Clipper internals by few years ago I made speed tests
and at list in CL5.2/CL5.3 there is no symbol table lookup. PCODE
evaluation is very fast comparable to static and locals and number
of memvar variables does not change the speed.
Maybe such situation happened with older Clipper versions.
The only one and very serious problem in Clipper is limited number
of memvars which can be used so programs which extensively used them
had very serious problems when reach this limit because many different
problems inside Clipper VM seems to be exploited in such case.

best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to