Hi Chris

Chris Palmer wrote:
> Please help, Can anybody please help with the following.  When I run the 
> following [sample] programme in Alaska it takes 73 seconds to run on an 
> older PC.  But, on the same PC when complied in Clipper, it takes only 3 
> seconds to run.  Can anyone help me speed up the process.
>  
> Thanks
>  
> [ Please note, this is only an example ]
>  
> use policy
> go top
> @10,10 say time()
> do while .not. eof()
>     @12,10 say recno()
>     dbskip()
> enddo
> @14,10 say time()

This is one of the first things any new Xbase++ user picks up.

Two things are obvious here:

1. when you do 'use policy' in clipper it opens the database exclusive.  I 
believe in Xbase++ it defaults to shared access instead, so you are not 
comparing like for like.  Shared access probably slows the process down.

2. the updating to the screen on your '@12,10 say recno()' line is now having 
to go through windows before getting to the screen, so that slows that bit 
down.  That's just the way it is.  If you want to improve this then you have 
to stop updating the screen so often.

Does that help?

Regan Cawkwell
Company  : Real Business Applications Ltd
Title    : Technical Support
Websites : www.rbauk.com   www.rba-uk.com   www.retailerexpress.co.uk
Email    : regan@rba-uk.com
------------------------------------------------------

It does explain it, thanks for your help




"Regan Cawkwell" <regan.cawkwell@virgin.net> wrote in message
news:$3d$J21kFHA.5608@S15147418...
> Hi Chris
>
> Chris Palmer wrote:
> > Please help, Can anybody please help with the following.  When I run the
> > following [sample] programme in Alaska it takes 73 seconds to run on an
> > older PC.  But, on the same PC when complied in Clipper, it takes only 3
> > seconds to run.  Can anyone help me speed up the process.
> >
> > Thanks
> >
> > [ Please note, this is only an example ]
> >
> > use policy
> > go top
> > @10,10 say time()
> > do while .not. eof()
> >     @12,10 say recno()
> >     dbskip()
> > enddo
> > @14,10 say time()
>
> This is one of the first things any new Xbase++ user picks up.
>
> Two things are obvious here:
>
> 1. when you do 'use policy' in clipper it opens the database exclusive.  I
> believe in Xbase++ it defaults to shared access instead, so you are not
> comparing like for like.  Shared access probably slows the process down.
>
> 2. the updating to the screen on your '@12,10 say recno()' line is now
having
> to go through windows before getting to the screen, so that slows that bit
> down.  That's just the way it is.  If you want to improve this then you
have
> to stop updating the screen so often.
>
> Does that help?
>
> --
> Regan Cawkwell
> Company  : Real Business Applications Ltd
> Title    : Technical Support
> Websites : www.rbauk.com   www.rba-uk.com   www.retailerexpress.co.uk
> Email    : regan@rba-uk.com
> ------------------------------------------------------

Regan, Chris,

> Two things are obvious here:
> 
> 1. when you do 'use policy' in clipper it opens the database exclusive.  I 
> believe in Xbase++ it defaults to shared access instead, so you are not 
> comparing like for like.  Shared access probably slows the process down.
> 
> 2. the updating to the screen on your '@12,10 say recno()' line is now having 
> to go through windows before getting to the screen, so that slows that bit 
> down.  That's just the way it is.  If you want to improve this then you have 
> to stop updating the screen so often.

3.  When Clipper performs a SKIP, it only does so logically. It does not
read the record until you attempt to read a field, at which time it will
settle the record pointr on the correct record.  RecNo() returns the record
number reported by:

   a) the index record (when an index is used)
   b) the logical record number held in the RDD

Therefore, RecNo() is insufficient to load the record data into memory.

When Xbase++ performs a skip on a shared file, it always reads the record
into memory.  In a multi-tasking networked scenario, this reduces
(illiminates!) delay at the point when the field data is requested, but is
inefficient when the record data is ignored.

To make your sample code behave equally in Xbase++ and Clipper, print to
the screen the value of at least one field and ensure that the file is
opened either exclusively or shared by implicit declaration:

use policy shared
go top
@10,10 say time()
do while .not. eof()
    @12,10 say recno()
    @12,40 say FieldGet(1)
    dbskip()
enddo
@14,10 say time()

Regards,

Phil Ide

*******************************************
*   Xbase++ FAQ, Libraries and Sources:   *
*   goto: http://www.idep.org.uk/xbase    *
* --------------------------------------- *
* www.xodc.org.uk - openSource Dev-Center *
*******************************************

I know karate, kung-fu, and 47 other dangerous words.

Phil Ide wrote:
> Regan, Chris,
> 
> 3.  When Clipper performs a SKIP, it only does so logically. It does not
> snip

That clarifies it a bit more.

Thanks, Phil.

Regan Cawkwell
Company  : Real Business Applications Ltd
Title    : Technical Support
Websites : www.rbauk.com   www.rba-uk.com   www.retailerexpress.co.uk
Email    : regan@rba-uk.com
------------------------------------------------------

Phil,

> <snip>
> 3.  When Clipper performs a SKIP, it only does so logically.
></snip>

So it should be good to have another function which performs such logical
thing, like

DBJump( <nRecordsToSkip>).

Then the users which do not need to read the skipped records would have a
faster app and their customers happier than ever.

Don't you think so?

Best regards,

Jos Luis Otermin
oterminATciudad.com.ar
Enjoy the growing Xbase++ repository
http://ar.groups.yahoo.com/group/XFreeProject/join

Jose,

>> <snip>
>> 3.  When Clipper performs a SKIP, it only does so logically.
>></snip>
> 
> So it should be good to have another function which performs such logical
> thing, like
> 
> DBJump( <nRecordsToSkip>).
> 
> Then the users which do not need to read the skipped records would have a
> faster app and their customers happier than ever.

Well, you can always emulate it like this:

  dbSkip( <nRecordsToSkip> )

The reason this works is because the DBE only ever settles on one record.
For example:

   dbSkip( 1 )
   dbSkip( 1 )
   dbSkip( 1 )

Will cause the DBE to settle on each of the records, causing the field data
to be loaded into the memory space of the application for each record.

   dbSkip( 3 )

...causes the index pointer to move to the 3rd record ahead of the current
index record.  Once it has settled on this record, the data component of
the DBE recieves an instruction to move to the beginning of the record
identified by the index record.  It achieves this by using the simple
algorithm:

  offset = (Record_Number * Record_Size) + DBF_Header_Size

Therefore, it never sees any other records than the record it started on
and the target record, so there is no loading of unnecessary records into
memory (unless you include both source and target records in that
category).

If no index is in use, dbSkip(3) will cause the current logic:


   Record_Number := Current_Record_Number + <nSkip>
   offset := (Record_Number * Record_Size) + DBF_Header_Size

..or possibly:

    current file offset is at the tail end of the current record!)
   offset := (Record_Size * (<nSkip> - 1)) + Current_Offset


Regards,

Phil Ide

*******************************************
*   Xbase++ FAQ, Libraries and Sources:   *
*   goto: http://www.idep.org.uk/xbase    *
* --------------------------------------- *
* www.xodc.org.uk - openSource Dev-Center *
*******************************************

Abandon hope, all ye who ENTER here!