BZZZZTTTT!!! Sorry! I'm definitely NOT in your camp on this...
I'm always careful to examine my code for efficiency, but NEVER at the expense of needless obfuscation and complexity for the programmer. I might have agreed with your statement about 30 years ago, when IBM midrange sported about 16K of memory, and processed at Khz speeds... Today, processing inefficiencies are much less impactful than before. A scarce assortment of high-performance routines might need to be coded for operational efficiency, but that impacts the api design NOT AT ALL.
I'd hazard that, since you wrap job number in a couple of days, that your applications submit MANY small jobs to jobq, for processing in batch. Each job instance requires significant allocation of resources to start up, initialize, execute, and end... A potential performance improvement to your design might be to use a prestart job to service requests from a data queue. This robust approach allows for several scalability improvements, such as a queue monitor which will start up additional PJs to service request backlog... Slick and performance ready!
-Eric DeLong
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Robert Houts
Sent: Tuesday, August 21, 2012 10:02 PM
To: RPG programming on the IBM i / System i
Subject: RE: Converting Case with a Varying Field
Sorry to disagree with you, as I do greatly respect your opinion, but processing efficiency ALWAYS trumps programmer efficiency. Any extra (read unnecessary) code is less efficient. The problem with most programmers (besides laziness) is that they usually don't look at the big picture, which is the code running in many jobs and possibly being called millions of times in a day. That "possibly negligible" amount of extra processing adds up in a hurry. Our production system does a lot of work (we wrap the job number every two to three days), so we need to remove inefficiency wherever we can.
It seems to me that however "very very fast" the bound calls are, calling the API directly is still faster. And that's the bottom line. Teaching programmers to value programmer efficiency over processing efficiency is a huge mistake.
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Barbara Morris
Sent: Tuesday, August 21, 2012 17:25
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Converting Case with a Varying Field
On 2012/8/21 7:03 PM, Robert Houts wrote:
... It
isn't rocket science and eliminates all overhead of the service
program. I guess that efficient processing is not a concern to you.
The Integrated Language Environment is optimized to make bound calls very very fast, with the intention that programmers can have many small functions that call each other rather than flattening out the functions to reduce the number of calls. So the cost of calling the two wrapper functions could be negligible compared to the actual upper-casing work.
And I think programmer-efficiency is a factor here. Even if you set up the copy file so all the other parameters can be used without further setup, coding the call to the API is still more complex and error-prone than calling the wrapper.
upper_value = CvtToUpper(some_value);
vs
QlgConvertCase(QlgConvertCase_To_Upper
: some_value
: QlgConvertCase_Temp_Output
: QlgConvertCase_Errcode_Give_Exception
: QlgConvertCase_Job_CCSID);
upper_value = %subst(QlgConvertCase_Temp_Output
: 1 : %len(value));
If I were maintaining this code, I'd much rather see the expressive call to CvtToUpper than the somewhat obfuscated call to the API. Even though I am completely familiar with this API, it's not immediately obvious which is the "real" parameter, some_value.
midrange.com
