Filepro-list Digest, Vol 29, Issue 12

[Boaz Bezborodko]

Steve Bergman wrote:
> Boaz Bezborodko wrote:
>
>>
>>>
>> Even though you are working on an indexed selection set you could be 
>> doing numerous other lookups within the program.  The problem could 
>> just as easily be a bug in the code that forces the process to go 
>> through the entire file on a looped, indexed search instead of 
>> terminating early when the search has gone past the search criteria.  
>> If the lookup is nested in another process the time to complete the 
>> task would grow exponentially with the growth of the data-set.
>> For example:  Let's say you need to looking through invoices on the 
>> basis of the check-number used to pay off the invoice for each check 
>> number in a set.  If you do a lookup by check number you want to 
>> check that the check number has gone past the number used in the 
>> search.  If you don't you'll end up looking through the entire file 
>> before getting out of the loop and doing the same thing on the next 
>> check number.  Cut off the search as soon as the check numbers are no 
>> longer equal and the process is much, much faster.
>>
>>
> Thank you for the help.  Nice to see that FP has such a thriving user 
> community after all these years. (Most of my customers that use FP 
> started out on Tandy Business Systems running Xenix with 5MB external 
> hard drives, have used their application for years and years, and 
> require *very* little support.  And they *never* talk about switching 
> to anything else!)
>
> I've looked over the table that seems to be taking fully 50% of the 
> overall time.  The loops he is using are of the form:
>
> -------
> If:                                                                   ?
> Then: lookup opo = ho.order  k=1    i=A -nx
> -------
> oloop | If: not opo
> Then: goto goon
> -------
> .
> .
> .
> -------
> If:
> Then: goto oloop
> -------
> goon | If:
> Then:
> -------
>
> That should exit the loop after all matching records have been 
> processed, right?
>
> One thing I just noticed, though, is a lookup loop on one table within 
> a lookup loop on another table in this processing.
> Also, automatic processing occurs on a record every time it is 
> accessed during output processing, right?  If the main table, and the 
> subsidiary lookup tables all have automatic processing defined, and 
> there is a lookup loop within a lookup loop within the main 
> processing, that could handily explain the relative slowness of 
> processing, couldn't it?
>
> Thanks,
> Steve
>
Yes, it could...Easily if it isn't properly programmed.

There are a number of things that could be happening here.  If he's 
using a a GETNEXT opo within the loop then it will keep looking past the 
matching records.  In other words, if you lookup "1234" then GETNEXT 
will still bring you to "1235" and the "not opo" instruction won't be 
met.  You will now go through all of "opo" before dropping out of the 
loop for however many records opo has.  It will do this every time it 
does this loop.  If this occurs in any other lookups as well or opo is a 
very big file then you really are doing a lot of unnecessary work.

In FP there is also the option of defining a different (or no) automatic 
processing when running a process.  The question is whether you need to 
run the auto processing or not.  Or even if you need all of it.  You can 
always copy the auto-processing file and modify the copy with only what 
is needed for the report.

Boaz