Re: Value vs. Const

[Hans Boldt <boldt@xxxxxxxxxx>]

David Gibbs wrote:

> At 05:53 PM 8/7/2003, you wrote:
>
> > Using VALUE for "large" parameters should be avoided.
>
>
> Can you define "large"?  Bigger than a breadbox?  Bigger than a truck?

Easy answer: It depends.

Longer answer: Sorry, but performance is a bit of a hot-button for 
me, so this answer is indeed rather longer.

"There are two types of programs: 1) programs with obviously no 
bugs, and 2) programs with no obvious bugs."

In my (not so humble) opinion, the first priority of a programmer is 
to write code that's clearly correct. Following that rule, CONST and 
VALUE have similar characteristics, but as someone else pointed out, 
CONST has certain consequences with respect to aliasing, which might 
result in instances of a particularly nasty class of bugs. So from a 
software correctness point of view, VALUE has an edge over CONST.

Of course, once your program runs correctly, often the next concern 
is performance. Although usually consider performance in the design 
of software, it absolutely has to take a back seat to correctness. 
After all, what's the benefit of a fast running program if it gives 
the wrong result?

When dealing with performance, it is absolutely vital to use good 
performance analysis tools, and to understand what the results mean. 
When trying to improve the performance of an application, you 
determine where the biggest bottlenecks are, and attack those areas 
first. The tools are also important in the analysis to determine if 
a particular change to the code does have a performance benefit. 
Often, changes made in the interests of performance have the 
opposite effect.

Since RPG applications are largely I/O bound, I/O is the first 
obvious realm to analyze. Database design is a big factor here, and 
the database analyst often has to balance competing factors. Often, 
higher levels of normalization (which are generally considered to be 
good from a database design point of view) have to be sacrificed in 
the interests of performance.

Secondly, choice of algorithm is a major area for analysis. This is 
an area where testing is vital, since improved performance in one 
area sometimes has an even worse detrimental effect somewhere else. 
I've found this myself in the ILE RPG compiler. I knew increasing 
the size of the hash table (used to index the symbol table) would 
improve the speed of name lookups. But a larger hash table slowed 
down the compile since the subsequent sort step took much longer!

FINALLY, there's the effect of individual bits of coding in the 
program. For example, reference versus CONST versus VALUE 
parameters. Once you've optimized your database, and once you've 
chosen the optimal algorithms, and if you still have concerns over 
the speed of your application, and if there are still obvious 
bottlenecks in your application, only then you should worry about 
individual statements or procedures. For example, if your 
application spends 5% of its time in a particular procedure, a 50% 
improvement in that procedure will yield a 2.5% improvement overall. 
Is that amount of improvement worth the effort? Maybe, maybe no. But 
that has to be factored in to your analysis.

Okay, all that preamble out of the way, let's assume your procedure 
call is indeed a bottlenck and you want, or need, to optimize it. As 
pointed out already, one thing to consider is long return values. 
Even if your return value is a varying length character string, the 
process of returning that string will move around the maximum length 
of the string. And so large return values should be avoided. On the 
other hand, returning potentially large strings can make your code 
much more readable and maintainable. (TANSTAAFL!)

Regarding parameter passing, the most flexible options are VALUE and 
CONST since you can pass anything you want, variables or 
expressions. Passing small (say register sized) scalar values by 
VALUE is most efficient, and so VALUE should be the standard for 
integer, unsigned, float, 1A, or indicator values. For larger 
aggregates, like character strings or data structures, CONST has the 
edge performance-wise, since it can, under certain circumstances, be 
optimized to passing a pointer to the original value. Otherwise, the 
value is copied to a compiler-generated temporary, and the address 
of that is passed. Also, for strings, varying length is generally 
faster than fixed length.

Now back to the original question 'Can you define "large"?'. The 
answer is "It depends". It's a tough call, but only good performance 
profiling can tell you what "large" is for your application.

Cheers! Hans

PS. Sorry for the lengthy answer, but like I said, performance is a 
bit of a hot-button for me. Often, I see people worrying about (for 
example) which opcode is faster than another, when they should be 
worrying more about bigger issues affecting performance, and using 
performance tools to verify their performance work. Also, many 
guidelines that were "common knowledge" in the days of programming 
on the S/38 or early AS/400's simply no longer apply today.

PPS. To digress further, and since this IS Friday, I'll just add one 
more point. Although compiled languages traditionally perform much 
faster than interpreted languages, more and more code is being 
written these days in the latter class of languages. Why? First, 
many shops have decided that the ease of writing bug-free on-time 
programs in an interpreted language far outweighs any loss in 
performance. Second, often these days the performance of an 
interpreted program is not that much behind that of a compiled 
program, especially if there are database or network latencies 
involved. Another factor is that a well written program is a modern 
interpreted language spends most of its time in the class library, 
which contains much code written in a compiled language, typically C.

PPPS. There's NO PPPS!