----- Original Message ----- >
----- Original Message -----
From: "Charles Wilt" <charles.wilt@xxxxxxxxx>
Crispin,
Slight correction, chain is faster only if the key being searched for
doesn't exist AND the key is greater than anything else in the file.
Otherwise SETLL is faster.
Charles
Charles,
Forgive me for being dumb. Isn't what you said more likely to result in
SETLL being faster?
"If the key being searched for doesn't exist AND the key is greater than
anything else in the file"
Surely that would mean that SETLL would not have to reposition because it
was already at end of file? Or am I completely missing what you are saying
(quite likely)?
But that is just anecdotal, as I don't know if SETLL still has to position
to end of file even if there is no key higher.
FWIW, I took a file with 15 Million records, and ran a test of CHAIN vs.
SETLL to determine if the record existed in the target file. I read the
input file in Primary Key sequence, and effectively wrote every record
found. The target file started off with 0 records, and had the same Primary
Key.
For CHAIN, it took 10:33
For SETLL it took 11:31
This system is our QA system, nothing else was running. It's a partition on
a 570 with 6GB of ram and 1.5 TB of DASD (44% utilization), running i 6.1.1.
Based on that, using a CHAIN produced almost 1000 more writes/sec. But, it
matches your statement of there being no record with a greater key. I'm just
not sure I understand why...
Of course, it could be completely different on another system.
I decided to take the WRITE out, and do the same READ/CHAIN vs. READ/SETLL
when the data existed in the to file for every record. I wanted to see the
impact of the CHAIN reading in the data.
I don't think anyone will be surprised at...
CHAIN 8:45
SETLL 7:15
Personally, I always thought that a SETLL would be better performing,
because no data is read into the buffer, the pointer is just moved. But it
seems that is not always the case, if there is no record to be found, CHAIN
appears to be slightly quicker...
Crispin.
midrange.com
