Re: Service Program Overhead

Here is a little blurb I wrote up for our programmers on parameters. Maybe
it will be of help.

How Parameters Are Passed



This document explains how parameters are passed between a program or a
procedure. The procedure can be in your program, another module or in a
service program. Always the same.



This document primarily applied to RPG but will apply to a CL if the module
or program is calling a procedure with CALLPRC and using by reference or by
value.


First three ways to pass a parameter.



1. BY REFERENCE – BY REFERENCE means that the parameters is passed by
getting a pointer to the variable and passing that pointer to the receiving
program or procedure on the stack. The receiving procedure or program then
references the variable through the pointer. This means that any changes to
the parameters are reflected in the variable in the calling program or
procedure. Use call BY REFERENCE only if you want to the variable in the
caller to updated. Note that you cannot pass a constant or an expression BY
REFERENCE. It can only be a field.



1. By CONST – BY CONST means that the compiler passes the variable the
same as BY REFERENCE but the receiving procedure try’s to keep you from
making any changes to the variable but this is not guaranteed. There are
ways to get around this and trick the compiler. In addition, even if you
code the CONST on the prototype for a program call, it means nothing in the
receiving program unless you create a prototype in the receiving program
specifying the parameter as CONST. The compiler will then attempt to prevent
any changes to the variable. Lacking this, the compiler treats a CONST just
like it is a pass by reference. Note also that with a CONST you can pass
constants or expressions. The compiler just evaluates them and pass a
pointer to a temporary variable.





1. BY VALUE – BY VALUE means that the compiler guarantees that the
variable will not be changed. It does this by pushing a copy of the variable
on to the stack and referencing the copy from the stack. When it finishes
the call, the stack is discarded. BY VALUE can only be used with a
procedure. It cannot be used with a program. In a program, it must be BY
REFERENCE or BY CONST since programs always reference variables from
pointers.


When to use each.



It depends on what you want to do in the receiving program or procedure. If
you want to modify the variable, you must use by reference.



If you are passing to a program, always code a prototype in both the calling
and receiving program and specify CONST unless you want to have modified.



If you do not want the variable modified what you use is dependent on how
big the variable is.



The basic rule should be when passing a variable is to use BY VALUE unless
the variable is large. BY VALUE guarantees that the variable will not be
modified.



For example, if you are passing an integer which is 4 bytes, you are best to
pass BY VALUE. Why? Because if you pass BY CONST you are copying a 16 byte
pointer to the stack vs. a 4 byte integer but the AS/400 is so fast on
procedure calls it would be hard to see the difference.



If you are pass a character string that is 64k probably better to pass BY
CONST. Otherwise the 64k bytes will be pushed onto the stack instead of a 16
byte pointer but the controlling factor is the question, “How important is
that this variable not be modified in the called procedure?”. If it is very
important, pass by VALUE anyway.


On Fri, Nov 13, 2009 at 1:31 PM, James Perkins <jrperkinsjr@xxxxxxxxx>wrote:

I am passing them by value, but that's only because they are pointers. I
don't think, I should double check but I'm feeling lazy ;-), that you can
pass a pointer as a const.

I knew CONST was faster, but I never really understood why until you just
explained it here. Thanks!

--
James R. Perkins
http://twitter.com/the_jamezp


On Fri, Nov 13, 2009 at 12:19, Birgitta Hauser <Hauser@xxxxxxxxxxxxxxx

wrote:

Just another question: Are you passing these huge variables by VALUE?
If so always a duplicate of the complete maximum length is generated a
populated with the values you pass.
Use CONST instead. When using CONST a duplicate is only generated if the
passed data type or length does not match with the expected data type or
length.

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training

them

and keeping them!"

-----Ursprüngliche Nachricht-----
Von: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx

]

Im
Auftrag von James Perkins
Gesendet: Friday, 13. November 2009 20:27
An: RPG programming on the IBM i / System i
Betreff: Re: Service Program Overhead

I am using some large variables, but they are varying so I don't think

they

should impact performance. My understanding is that varying length

strings

don't allocate storage until you tell them how much to allocate, but I
could
be wrong.

That being said, that was why the performance was extremely poor the

first

time, hours that is. I had a huge string I was using because I forgot the
lovely varying keyword.

--
James R. Perkins
http://twitter.com/the_jamezp


On Fri, Nov 13, 2009 at 11:07, Dennis Lovelady <iseries@xxxxxxxxxxxx>
wrote:

It seems that the invocation of subprocedures in a service program
significantly slows down performance. I invoke 2 subprocedures on

each

write
to the stream file, a replace all subprocedure and the write line
subprocedure. So, for the question, what kind of overhead is there

when

invoking subprocedures from a service program? I'm sure there is
information
on this, I just can't seem to find it.

There are lots of ways to impact performance positively and negatively.
Usually when I hear someone complaining about the performance after
modularizing a program, I find that the real issue is that they're

passing

huge variables (rather than pointers to them), and this is a documented
costly technique.

You're not doing that, are you?

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"Get your facts first, and then you can distort them as much as you
please."
-- Mark Twain

--
This is the RPG programming on the IBM i / System i (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.

--
This is the RPG programming on the IBM i / System i (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.


--
This is the RPG programming on the IBM i / System i (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.

--
This is the RPG programming on the IBM i / System i (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.