On Wed, 16 Sep 2009, Miguel Angel Marchuet wrote:
Hi,
> Results of test:
> with const 32.41 seconds
> without const 32.34 seconds
> Press any key to continue...
> Demostration :
> #DEFINE REC_TEST 100000000
> FUNCTION MAIN()
> LOCAL p, n
> REQUEST HB_GT_WIN
> p := Seconds()
> FOR n := 1 TO REC_TEST
> CallConstTest()
> NEXT
> ? " with const " + AllTrim( Str( seconds() - p ) ) + " seconds"
> p := Seconds()
> FOR n := 1 TO REC_TEST
> CallTest()
> NEXT
> ? " without const " + AllTrim( Str( seconds() - p ) ) + " seconds"
> wait
> RETURN NIL
> #pragma BEGINDUMP
> #include "hbapi.h"
> HB_FUNC( CALLCONSTTEST )
> {
> const int posmotrim = 100;
> hb_retni( posmotrim );
> }
> HB_FUNC( CALLTEST )
> {
> int posmotrim = 100;
> hb_retni( posmotrim );
> }
> #pragma ENDDUMP
Miguel above example quite well illustrates what you are doing.
In the above test you cannot measure anything because such trivial
code is fully optimized even by the most stupid C compilers and
any variable is not created at all but 100 value is pushed directly to
stack (or register in some calling conventions) and posmotrim variable
is not created at all.
Here is assembler output for CALLTEST(), CALLCONSTTEST() functions generated
by GCC:
HB_FUN_CALLTEST:
pushl %ebp
movl %esp, %ebp
subl $8, %esp
movl $100, (%esp)
call hb_retni
leave
ret
HB_FUN_CALLCONSTTEST:
pushl %ebp
movl %esp, %ebp
subl $8, %esp
movl $100, (%esp)
call hb_retni
leave
ret
and by BCC5.5:
_HB_FUN_CALLCONSTTEST proc near
mov eax,100
push eax
call _hb_retni
pop ecx
ret
_HB_FUN_CALLCONSTTEST endp
_HB_FUN_CALLTEST proc near
mov eax,100
push eax
call _hb_retni
pop ecx
ret
_HB_FUN_CALLTEST endp
As you can see for both functions exactly the same code is generated
so there is not difference at all. Your test only shows that in your
windows machine process timer is updated irregularly and there are
some small differences for the same code executed twice. Nothing amazing.
Each of us who run the same test twice found that such small differences
exist in all system though usually in *nixes they are much smaller then
in windows.
The problem is that you haven't check anything but created theory
on random results and it's not the 1-st time.
Finally I've found time to verify if REDBFCDX or HBNETIO is faster then
SMB protocol and in local lan 100 it isn't at all. The lan overhead is
such huge that there is no difference at all and your tests results you
send here are absolutely false and it's result of your more or less
intentional bug in REDBFCDX code, source/rdd/bmdbfcdx/redbfcdx1.c[155]:
static BOOL bTurbo = TRUE;
this line disable read index locks what may cause any unpredictable results
in concurrent access when other station write to index file, in some cases
even GPF or internal error.
So if any of you plan to make real test please do not forget to add to
your test code:
RE_TURBO( .F. )
or if you want to compare dirty read performance in REDBFCDX with other
RDD then use:
Sx_SetTurbo( .T. [, <cRDD> ] )
so both will use unprotected index reading. I've already made such tests
and in LAN there is no difference at all. In T100 native DBFCDX using SMB
protocol and DBFCDX using HBNETIO library and REDBFCDX in xHarbour gave
the same results. Just simply both have to exchange the same number of
ethernet frames and this is the most expensive part of tests so other
differences are not noticeable. The difference can be seen only in local
access (~100 times faster when Harbour is noticeable faster) and maybe
in some WAN where SMB needs additional overhead but here I haven't made
any real test and I can only guess.
So finally xHarbour has in practice unnecessary copy of core DBF* RDDs
with "RE" prefix due to typo (I want to believe unintentional) in one
of copied RDD code which seriously affected your test results because
by default read locks are disabled.
best regards,
Przemek
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
xHarbour-developers mailing list
xHarbour-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xharbour-developers
