Re: Value vs. Const -- RPG400-L

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!