Post by Przemyslaw CzerpakHi,
Post by Massimo BelgranoWill be intresting this discussion on fivetech forum?
http://forums.fivetechsupport.com/viewtopic.php?f=3&t=15076
No,
Post by Massimo BelgranoSpeedtest CLIPPER vs. xHarbour - COMMIT
Is CLIPPER still faster in database management?
No,
Post by Massimo BelgranoI am testing the COMMIT statement.
With Clipper the operation takes 9 sec. with xHarbour 77 sec
function main()
local I:=0
msginfo("Start " + str( seconds() ))
use clientes new
for I := 1 to 1000
append blank
clientes->nombre := str(recno())
commit
next
msginfo("End " + str( seconds()) )
return nil
In the past at least five times I was answering for similar questions.
I hope this is the last time. What commit() does is quite well documented
in Clipper. I suggest to read also COMIX documentation and check what
cmxSys( 1002 ) does.
I think it's a basic information which should be well known by anyone
who is working with Clipper.
1. write application memory buffers to file.
2. send to OS request to flush disk buffers releated to open file.
The 1-st action is executed also by any other rdd operation which
may cause record reloading or may need to synchronize modifications,
f.e. unlock. You can simulate it in many different ways, f.e. by skip(0).
The 2-nd action is unique to dbcommit and it's not necessary for any
synchronizations in simultaneous/concurrent/network access. The whole
job here is sending information to Operating System which is automatically
redirected if necessary by OS to File Server that we ask to flush OS or
FS disk I/O write buffers physically to disk. OS / FS can ignore our request,
can execute it immediately or can only mark that it should be done
in some nearest future. It's in practice out of programmer control and
does not have to be.
set( _SET_HARDCOMMIT, .F. )
cmxSys( 1002, .f. )
As I said it does not cause any interactions to concurrent access.
Try to add set( _SET_HARDCOMMIT, .F. ) to above code and check the results.
Then write a message to your OS / network client / file server authors
and ask why COMMIT request executed from DOS application makes sth different
then executed from real Windows application. Of course if you need such
information. Probably DOS emulation layer buffers few commit requests in
some short time period, f.e. 1 sec. and then send them as one. But I only
guess. Anyhow it's not Harbour problem. Harbour only sends commit request
for open file handle to the OS and this is single function call inside
each user dbCommit() if _SET_HARDCOMMIT is not disabled. All time overhead
if any is out of Harbour code.
best regards,
Przemek