Re: When is %EOF not an %EOF

[Hans Boldt <boldt@xxxxxxxxxx>]

DeLong, Eric wrote:

> Thanks for the clarification, Hans.  I agree with you about coding for
> correctness and maintainability, but please don't trivialize a 5 or 10
> percent performance boost.  Sometimes that is all it takes to turn a
> "failure" into a "success".  Also, while I don't doubt that there are many
> factors that contribute to the perception that reade is a pig, I find it
> very interesting that by simply changing a reade to a read and then testing
> the keys manually can improve performance so dramatically. 
>
> Regarding performance testing tools, what can I say.  I'm an RPG programmer
> and I use whatever comes with the box, good bad or ugly.  ;)  

Granted, my experience is different than yours, but I've always seen 
performance either as a red herring or as black magic. With the best 
of intentions, you can make a change with the goal of improving 
performance, only to see the opposite effect.

I agree there may be times where a 5% or 10% performance improvement 
can make or break a borderline project. But the difference can 
easily be lost in the error bars if something else in the system 
changes. An improvement in one area may have a detrimental effect 
elsewhere. Or production data may have different characteristics 
than test data. Often the only sure way to improve performance is to 
simply throw more hardware at the application.

Regarding READE, it's always been a thorn in the side of RPG 
development. At least, that's been my observation over the past 22 
years. Back in the S/38 days, there were significant performance 
problems with sparse keys and logicals over multiple physicals (if 
memory serves), which is why the "get next key equal" request was 
added. But there were still significant semantics mismatches, which 
is why the Factor-1 blank form was added. When implementing SAA 
RPG/370 in the late 80's, READE was the trickiest to get right. It's 
simply too weird a hybrid between a sequential and an indexed operation.

Bottom line: Without any specific performance justification, I 
wouldn't disagree with any recommendation to avoid READE. Or if you 
have to, use the *KEY form of READE.

Cheers! Hans