Re: Service Program Argument Optimization

[Steve Richter <stephenrichter@xxxxxxxxx>]

On Thu, 13 Jan 2005 17:44:54 +1100, Simon Coulter <shc@xxxxxxxxxxxxxxxxx> wrote:
> 
> On 13/01/2005, at 10:58 AM, Tony Carolla wrote:
> 
> > I have created six modules, and then created a service program from
> > these (my first one YAY!).  I was displaying the service program, and
> > on the Procedure Exports screen, all of my procedure exportes are
> > listed, and the 'Argument Optimization' field says *NO.  Now, I am
> > curious.  The help text speaks of some mysterious way of optimizing
> > the passing of args to ILE procedures (which I am doing).  All six of
> > these procedures in the service program receive a single 140 Alpha
> > parameter, by value.  i.e.
> >
> >      D CBI_R061        PR                  LikeDS(temp_Box)
> >      D  ReportLine                  140A   Value
> >
> > Now, to me, passing 140 bytes to an ILE procedure would be a great
> > candidate for optimization.  Is there some way, while creating the
> > module, to specify this optimization is to take place, or to be
> > attempted?  Is it when I create the service program?
> 
> ARGOPT support is compiler specific. C supports it via the #pragma
> argopt() directive. It optimises parameter passing by trying to keep
> space pointer parameters and space pointer return values in registers.
> 
> I think that C (and possibly its incremental derivative) is the only
> OS/400 programming language that supports this feature.
> 
> Why are you passing string parameters by VALUE? If you're worried about
> space you should be passing by constant reference using CONST. In
> general, you should use CONST and avoid VALUE unless the interface you
> are prototyping requires it (i.e., a C-style interface you have no
> control over).

On principle, I prefer to pass by value instead of by const reference.
 It just reinforces my higher principle of modular code. That the
variables of the called proc should be completely seperate from those
of other procedures on the call stack.

There is a subtle bug that can be introduced into your code when
passing by const reference instead of by value. If your proc has two
parms, one is passed by const ref and the other by plain old
reference, ..... and the caller passes the same variable for both
parms ......   then any change the called proc makes to the passed by
ref parm will be reflected in the passed by const ref parm.   Not very
likely, but it can still happen.

I have used pass by value instead of pass by const ref whenever the
parm is small.  16 or maybe 32 bytes or less.  Not because of the
above stated reason, but because I thought it would actually be
faster.  The thinking being that passing by reference involves setting
a pointer to the callers variable, then passing the pointer by value
to the called proc.  Passing by value, I guessed, would skip the set
the pointer step and simply copy the variable value to the called
procs parm variable.

But before posting this universal truth, I tested it.  My assumption
that passing by value would be faster than passing by reference would
be faster was wrong.  Passing an integer by value is actually a notch
slower than passing an integer by const reference.  Hardly a
difference worth considering actually.  50,000 calls took 36
milliseconds to pass by value compared to 34 to pass by const
reference.  It is interesting to me however because it invalidates my
assumption of how the compiler passes parameters.

-Steve