On Thu, 26 Nov 2009, francesco perillo wrote: Hi,
> > If you are asking about runtime speed overhead caused by longer variable > > names then there is no difference if you are using shorter or smaller > > variables names. LOCAL variable names are not stored in final binaries > > at all (with the exception to code emitted for debugger with -b switch) > For LOCALs, ok. They have a certain visibility and the compiler can > create optimized code. > For PRIVATE/PUBLIC... I can create these variables at runtime using > macros or internal calls... Yes it is but also in macro compiler they are accessed using addresses in symbol table. Looking for address is symbol table is done using binary search. > > > and PUBLIC, PRIVATE, FILED variables are not accessed by name but using > > pointers to symbol table > Sorry, just to have more infos.. > > Imagine a PUBLIC variable created at runtime; in this case the > compiler can't refer directly to symbol table position but must lookup > the variable name at runtime somehow... I may understand from your > words that harbour creates a local symbol table with only the variable > names and then does a "runtime binding" when entering the function.... > in this way it can handle visibility PUBLIC/PRIVATE... > In this way, in the pcode harbour only references "position 1 in the > symbol table" and it will be runtime engine to fill it with correct > values (or pointers to correct values....) > I imagine it is more complicated than this, I just wanted to validate > the general idea.... When you compile code which uses memvars (public or private variables) then compiler generates references to symbol table which is register in global symbol table at application startup so later when application is executed it does not cause any speed overhead. Just simply accessing memvar variable which is <n>-th symbol in generated symbol table we have PCODE like: HB_P_PUSHMEMVAR <n> and then it's executed as: hb_stackPush( symbol_table[ <n> ]->memvar ); without any name lookup, etc. As you can see in speedtst there is very minor speed difference (in practice unnoticable) between locals, statics and memvars. When you create memvar variable dynamically using macro compiler (in code like: 'var := 1' compiler knows that 'var' variable should be used and if it does not exists created so it adds 'var' to module symbol table and use this entry to access corresponding memvar variable without any name lookup) then macrocompiler also converts all symbols in compiled text into references to global symbol table and then generate PCODE which operates only on such addresses in similar as in PCODE generated by compiler but instead of using module symbol table it stores addresses directly in generated PCODE. So during execution there is also no name lookup. The only name scanning is part of macro compilation process and it uses binary search scanning global symbol table. Such scanning is done for all symbols in macrocompiled code, i.e. function and message names or fields not only for memvars and here the length of used symbols is in practice unimportant for speed. To see the difference you will have to create some program which will use only symbols like: "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA001" "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA002" [...] "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXYX" [...] for all memvars, fields, function, messages, class names, etc. and even in such case the speed difference will be very small and hard to measure/notice and of course it will effect only the cost of macrocompilation but it's absolutely unimportant for later execution of such macrocompiled code. The same is in Clipper though the maximum symbol length (10 characters) is smaller then in Harbour. I know that you can find some incredible theories about memvars in Clipper using different mail list archives but 95% of them was created by people who did not know too much about real Clipper internals. Probably the only real serious problem with memvars in Clipper was limited size of global symbol table in 16-bit applications and then series memory problems which were exploited when this limit was exceed. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
