Buenisimo, como siempre ! Gracias przemek
Przemyslaw Czerpak escribió en mensaje <20090401095625.ga8...@uran.home.aster.pl>... >On Wed, 01 Apr 2009, Massimo Belgrano wrote: > >Hi, > >> Will be intresting this discussion on fivetech forum? >> http://forums.fivetechsupport.com/viewtopic.php?f=3&t=15076 > >No, > >> >> Speedtest CLIPPER vs. xHarbour - COMMIT >> Is CLIPPER still faster in database management? > >No, > >> I 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. > >dbCommit() make two things: > 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. >In [x]Harbour you can disable this part of dbCommit() by: > set( _SET_HARDCOMMIT, .F. ) >In COMIX by: > 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 _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
