Re: CallP Versus Program 'CALL'

Interesting how much faster IBM has been able to make the program call in
the last few years. The difference used to be huge but they cut it way down.

10 million calls on an unloaded Blade Server V7R1

Service Program 1.009 seconds
No Cycle (Main Keyword) Program Call 23.348 seconds
Cycle - LR Off 31.78 seconds
Cycle - LR On 32.355 seconds

I believe that my original point is still true. Program calls have gotten
faster but service programs are a different way of thinking.

My best example is that back in V3R7 I was looking at a project. We had a
very complex pricing system. The CEO was trying to make it too complex for
a competitor to figure out a price. A waste of time since the customers
only carried about the net price.

Previous programmers had done the monolith thing and put all the logic to
do the calculations in three different programs written in three slightly
different ways in the three programs. It was nightmare to make a change.

When I looked at it from an ILE perspective, I released I had three
different methods. GetBasePrice, GetCustomerPrice, GetDiscountDetail.

Each one had its own parameters and GetCustomerPrice called GetBasePrice to
get a base price.

I suppose their would be some way to program this using a program call but
I would call that a mess. Three separate programs but where do you store
the discount details generated by GetCustomerPrice.The only way I can think
of practically would be to pass 7 different parameters on every call with a
flag to say what function to preform and array of records of some kinds to
return discount details.

The solution in ILE and a service program was simple and clean. With a
program call, ugly. What happens if I want to add new method?

Encouraging people to use program calls just doesn't make sense to me.







On Mon, Feb 11, 2013 at 2:54 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

On 2/11/2013 4:34 PM, Ken Sims wrote:

Hi Buck -

On Mon, 11 Feb 2013 14:53:06 -0500, Buck Calabro wrote:

On 2/11/2013 2:38 PM, Vernon Hamberg wrote:

I didn't see a test for a CALLP of an EXTPGM vs CALLP of EXTPROC.

As you know, CALLP is not "call procedure" - it is "call prototyped"

and

can either be to a program or a procedure.

I'd expect CALLP - EXTPGM to perform about the same as a regular CALL.
But I've not tried it.

<snip>

I figured that I'd post performance numbers since the OP asked about
relative performance. I missed which relatives he was looking to
compare :-)

CALLP of an external program is just another form of CALL.

CALLP of a procedure is just another form of CALLB.

So really you were comparing CALL and CALLB.

Seems right to me.

I was conflicted posting these numbers because empirical evidence is
really only a snapshot of the current hardware/software combination. It
is possible, however unlikely, that the hardware or software of the
future could result is a different outcome. Without a manual reference
stating that this is intended to work just this way, IBM is actually
free to change the way it all works. Which is fine by me considering
all the cool new toys I've been able to play with recently.

The downside is that someone will read these numbers, make up some shop
standard for the ages and in 2030 will be wondering why his 'guaranteed
performance' isn't working out. Sort of like the advice we all heard
many years ago when we were told that too many logical files killed
performance. Or that journalling killed performance. Or that MULT was
faster than DIV.

I think the only real takeaways here are that sub-procedure calls are
quite fast compared to program calls, and that it takes a fair amount of
time to create a new activation group. The system is pretty much
behaving the way we think it ought.
--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.