RE: Speed of SETLL/GT vs CHAIN

[Buck Calabro <Buck.Calabro@xxxxxxxxxxxx>]

Viji wondered:
>would the gurus out there please clarify if 
>the actual time for a SETLL is
>faster than CHAIN.

Someday I'll make a test suite that I can use to measure all this stuff
(wait - isn't IBM's CPW for this?!)

Anyway, I have found that results vary depending on the underlying hardware
(CISC v. RISC, more cache on DASD, etc.) and the OS release level (including
PTF's) and the underlying data (clumped keys v. evenly dispersed).  So CHAIN
may be faster today, while SETLL comes out faster after the next bunch of DB
Group PTFs.

To settle this bet for your machine, write some programs to load up a work
file with records that match your desired keyspace (you want to control as
many of the variables as possible) and then go grab the records in the order
you want: one pass with SETLL/READ and another pass with CHAIN.

You are probably not interested in One Single Chain v. One Single Read,
because the I/O time for One Single record cannot be extrapolated to n
records because of OS/400, I/O adapter and disk caching as well as
asynchronous predictive read-aheads.  Record blocking will affect the
results too.

If you really want to benchmark this sort of thing, write a tool to convert
all your CHAIN opcodes into SETLL/READ.  Create the application in a
separate library.  Turn on job accounting.  Have the users run for a week
with the CHAIN version and a week with the SETLL version.  Compare job
accounting numbers and see which one wins out for Your users on Your machine
with Your data.  That is the truest test of all.

I would never try to say "x performs better than y" until I actually tried
both in my own environment.

Good luck!
Buck Calabro
Commsoft; Albany, NY
"Nothing is so firmly believed as
 that which we least know" -- Michel Montaigne
Visit the Midrange archives at http://www.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
+---