Re: Expensive op codes

[Vanja Jovic <vanja@xxxxxxxxx>]

All, 

firstly, I wouldn't like to take a credit for these tests. Original
author is Dave, and Martin probably "cut 'n paste" my name over his
post. I am the author only of the original comment that READ - IF might
be faster than READE. 

Now, with regards to question below, it's not about cycle read vs
program READ. It's about not using op codes which will prevent HLL from
requesting blocked input or output. There is a whole "theory" about
blocking, but in very simple terms, here is the bottom line:

Generally, you can expect blocking to occur with input only files,
providing that program doesn't perform any random access operation, and
with output only files, providing that there is no logical file with
UNIQUE key, built over physical. In RPG, READE will prevent program from
requesting blocking, and that means that program will have to "reach
out" for any new record required by READE statement. In same scenario,
SETTLL .. READ .. DO WHILE .. READ .. ENDDO will read block of records
into program memory during the first read, and then each subsequent READ
will pick record from there. Obviously, to achieve same functionality,
program not using READE will have to have more complex logic, and a few
more op-codes, but as test shows, it pays in the long run. CHAIN is
considered to be random access operation, but in newer versions of RPG
IV, there is a keyword BLOCK(*YES, *NO) on F spec, that will force RPG
program to request blocking even if CHAIN is being used. For the full
list of op-codes and their influence to blocking, refer to RPG manuals.

There is another side of the story. Database manager will do its best to
provide optimum performance for blocking, but if you think you know
better, there is a way to influence it. OVRDBF command is one of them.
>From Dave's tests, it's visible that he calculated number of records to
block, based on buffer size of 64K (SEQONLY parameter). There are other
parameters (NBRRCDS, FRCRATIO), that will influence program performance
under various circumstances (whether it is input or output file,
physical or logical, keyed or naturally sequenced..). There are some
traps, that one should be aware of, but, as we could see, gains are so
big, that it always pays to pay attention during program design. My
experience is that it is possible to get about 6 times better
performance. But, this is one of the areas where behavior in the
development environment will tell you very little, and will usually show
different results than behavior in production. That's why, tests with
big data volumes, and memory allocation, as similar to production boxes
as possible, is crucial for successful optimization.

At the end, to answer your question, everything else being the same,
cycle read (to input file) will most likely have similar performance to
READ .. IF over whole file, and will most likely start new CYCLE WAR.

Have fun,

Vanja Jovic,
Canada

boothm@earth.goddard.edu wrote:
> 
> Firstly, thanks for the info.  It is interesting, and not at all the
> results I would have predicted excepting the results obtained when you
> removed the K.
> 
> What I am still curious about though is: What would have happened if you
> had used the cycle to process the same records?  No READ, no READE, just
> InputPrimary on the keyed file.
> 
> Please respond to RPG400-L@midrange.com
> Sent by:        owner-rpg400-l@midrange.com
> To:     RPG400-L@midrange.com
> cc:
> 
> Subject:        Re: Expensive op codes
> 
> Vanja Jovic wrote:
> 
> Both test runs used OVRDBF FILE(ECLL02) SEQONLY(*YES 341)
> Both test runs read the entire file by key.  Program 1 used READE, program
> 2 used
> READ and compare.
> 
> Program 1 elapsed time was 33 minutes 38 seconds.
> Program 2 elapsed time was 12 minutes 38 seconds.
> 
> I think I will be using the READ/Compare model versus the READE model
> whenever
> possible when I need to read by key.
> 
> By the way, reading the non keyed physical file with the same OVRDBF only
> took 1
> minute 22 seconds.
> 
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---