On Tue, 22 Dec 2009, Andi Jahja wrote: Hi,
> I'm very sorry orry, I must be pointing to the wrong codes. > But have you tried to clean build with: _HB_API_INTERNAL_ With this yes just after your message and it works though I've found some problems with casting in C++ mode which I fixed and even serious bug in cairo code also fixed. > HB_STACK_MACROS and HB_API_MACROS defined? These macros do not work for external code in Harbour. They are reserved only for internal code for some limited situations (usually some C compilers which do not have good optimization logic with automatic function inlining) and can be safely used only locally. HB_STACK_MACROS causes that wrong code is generated which cannot be used in MT programs. This code needs to access hb_stack global variable what causes that less efficient slower code have to be generated which calculated offsets at runtime (not during compilation) when members of hb_stack are accessed from code used in different DLL modules (hb_stack is declared with import attribute). Additionally it does not allow to declare hb_stack as static variable in ST HVM what may badly interact with some compile time optimizations - for static variables compiler may chose optimal representation because it know all references to this variable at compile time so it's easier to optimize the code. In summary they can be reactivated only with some limited functionality for ST programs with the cost of reduced speed. I do not think that anyone will want to invest time in such modification. HB_API_MACROS replaces one function call with other or when used without HB_STACK_MACROS with two different ones. In Harbour whole HVM code is compiled as single hvmall.c file by all compilers which supports function autoinlining (from popular modern compilers only BCC does not support it). It means that functions like hb_ret*() are highly optimized by C compiler and already flatten (all nested functions inlined) so in the best case HB_API_MACROS give the same speed as native function call but in the worst one when used without HB_STACK_MACROS it will reduce the speed. With few modifications they can be reactivated but for modern C/C++ compilers they will only reduce the speed and any code compiled with above macros will be hardcoded to work only with less optimal ST HVM version. Keeping the code clean and friendly for C compiler optimization logic is the best way to improve the speed. Just compare the speed of Harbour and xHarbour where nearly everything is "manually inlined" using some modern C/C++ compilers like new GCC or MSVC versions. You can use tests/speedtst.prg. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
