Reading files into data structures is supposed to be faster. I don't know the specifics as to why, so I'm loathe to say, but I believe it's due to how it moves the entire record into the data structure instead of moving the data field by field.
I'm not sure what kind of impact you're looking to get, or what kind of shop you're at, but if you do high volume data processing, here are a couple tips that may help:
* When doing an array lookup, and the array was loaded by the program, only perform the lookup on the loaded elements, instead of on the entire array. So if the array holds 9999 elements, but only 2500 were loaded, it would only look through the 2500 elements. (This is probably smart regardless of the type of shop you're in.)
* Define local variables using the Static keyword. Be careful with this, and know what you're getting into with static, but if a procedure is called millions of times, keeping variables in place in memory may help to eliminate some of the overhead of calling the procedure over and over.
That's all I've got off the cuff.
-Kurt
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Buck Calabro
Sent: Thursday, January 03, 2013 12:44 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Suggestions on Speeding up a program
On 1/3/2013 9:43 AM, RPGLIST wrote:
I'm looking for any and all suggestions on possible ways to speed up
some programs.
The typical ones that come to mind are:
1. avoiding open and closes on files
2. Not setting LR when calling a program or procedure multiple times
3. using Data structures for block reads and writes
Any other suggestions?
Random poking is the least efficient way of improving performance.
Measure, measure, measure and then you know where the low performing areas are.
In my experience, the number one bottleneck is I/O. Typically, we do way too much of it. Imagine a customer master file with 50 columns, 500 total bytes long. Our RPG program does a CHAIN to get the customer's name and address. The database needs to shuffle all 500 bytes to the RPG buffer, which in turn needs to map 50 columns to 50 fields. We actually need a quarter of the bytes and only 5 fields. And we do that CHAIN for every one of a million transactions. That's a lot of bytes to copy and discard and a lot of fields to map and ignore because someone in 1986 thought it was a bad idea to make a logical file containing only name and address.
But measure it! It could be anything, including a giant sized return value from a function call.
Have a look at iDoctor.
https://www-912.ibm.com/i_dir/idoctor.nsf
--buck
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
midrange.com
