× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On Wed, 2005-12-14 at 14:46 -0800, Tony Carolla wrote:
> I have written many data warehouse routines, that churn through record
> counts in the hundreds of millions.  And because speed has been the
> principal goal (other than accuracy), I have conducted many tests using READ
> vs. READE.  I have found that the real difference between the two is that
> READE is doing a LOOKUP each time it runs, while READ is obviously only
> grabbing the next record.  
A lookup?  You mean SETLL?  


> If you use READE and specify BLOCK(*NO), versus
> using READ and specifying BLOCK(*YES), and overriding the block size to an
> I/O block of 128k, the differences are very real.
Of course, if you can do sequential I/O it will tear the wheels off of
indexed I/O.  But that's not the point here.  This test is to compare
indexed I/O using READ + test to indexed I/O using READE, and letting
OS/400 test.  

I merely want to see what sort of performance boost I would see if I
followed the advice I've seen here to replace READE with READ + test.  I
have found that the difference in not dramatic, but it is measurable.
The difference starts to get meaningful if block(*yes) is specified.

> 
> One of the key things to watch out for though, is if you use READE, and
> specify BLOCK(*YES), as Scott suggested for the test.  In this case, you are
> doing a DB LOOKUP, reading a block-size buffer of records, and tossing the
> entire block out at the start of each READE operation -- now that is the
> worst case, and will result in staggering performance differences.
Actually, you get a severity 10 compiler error RNF7092, indicating
block(*yes) will be ignored.  See Scott K's message on this earlier.

> 
> So I don't believe I have ever 'bashed' READE, it is good for certain
> operations, and for smaller volumes.
Uh, I don't mean you personally bashed it, just that the general
consensus over the past week or two *seems* to be that READE = slow,
READE + condition = fast, and I decided to test this assertion.  I don't
see much difference in the files I was using to test.  12.5%, though,
makes me consider using it more, but not necessarily going back to all
programs and making this change.

>   You just have to consider what the
> goal of the program is.  
Always.

> I have gone so far as to study the file being read,
> and figure out what the average/max/min records per account is, and set the
> block size accordingly, to read all of account's records in one READ.
If SETLL + READ can block successfully,  SETLL + READE should also be
able to do the same.  That it cannot is an implementation deficiency, in
my humble opinion.  

> 
> Bottom line -- If you are asking about performance, you are going to get
> advice from people like me that are willing to go the extra mile for those
> few seconds/minutes.
Do you write it all in RPG, or perhaps some MI ?


Regards,
Rich


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.