RE: No Subroutines (was Re: Debugging many subprocedures)

While it's true that the conversion will cause a performance hit and while it's 
certainly nice to know how big of a hit; there seems to be one thing often 
overlooked.

If you've got a value that needs to be passed into a procedure and the 
attributes of the variable don't match the attributes of the parameter, you've 
only really got two choices: let the compiler handle the conversion, do the 
conversion to a temporary variable yourself.

I'm guessing the compiler will be as fast or faster than doing it yourself.

Thus, from a performance standpoint, there's no reason not to use CONST.

However, this doesn't mean you can't use CONST improperly and cause a big 
performance hit.  Such as on a large character parameter, when the variables 
passed are often orders of magnitude smaller, without using VARSIZE and ideally 
VARYING.


Basically, all I'm trying to point out is that "performance considerations" are 
not a reason not to use CONST or VALUE.  If a parameter is not changed by a 
procedure, then it should have either CONST or VALUE.  But for "performance 
considerations" you need to understand CONST and VALUE and use them correctly.


HTH,


Charles Wilt
--
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
 

> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Paul Morgan
> Sent: Friday, July 29, 2005 5:37 PM
> To: rpg400-l@xxxxxxxxxxxx
> Subject: Re: No Subroutines (was Re: Debugging many subprocedures)
> 
> 
> Kurt,
> 
> If the parameter passed doesn't match the required parameter 
> (size, decimals
> and numeric type) the compiler can safely convert the 
> parameter to the right
> format.  This copying/conversion of the parameter before the call is a
> performance hit.
> 
> Paul
>