Re: Converting Case with a Varying Field

hi Robert,

On 8/21/2012 10:02 PM, Robert Houts wrote:

Sorry to disagree with you, as I do greatly respect your opinion, but
processing efficiency ALWAYS trumps programmer efficiency. Any extra
(read unnecessary) code is less efficient. The problem with most
programmers (besides laziness) is that they usually don't look at the
big picture, which is the code running in many jobs and possibly
being called millions of times in a day.

There are situations where a program that focuses solely on programmer efficiency will perform unacceptably slow. When that happens, the performance problem should be solved, even if it comes at the expense of programmer productivity.

Given the extraordinarily high volume you describe in your shop, perhaps this is a much more frequent occurrence for you than it would be for others. But in most shops, situations where performance trumps programmer productivity are the exception, not the rule.

It does not pay to spend 10 times as long developing code, and 20 times as much effort to maintain it just to save a few seconds of processing time a day.

And as for the sample code referenced in this thread (Gary Guthrie's CvtToUpper routine) the big problem with performance in that routine is NOT that it calls an extra subprocedure to invoke the API. Instead, it's the fact that it has a 32k return value. In current releases, it's performance could be drastically improved by adding the RTNPARM keyword -- but, of course, that code was written more than 10 years ago, long before that keyword existed. I'm sure Gary knew that he could improve the peformance by returning the output through the parameter list, but he opted for something that's easy to call rather than something that'd perform optimally.

And, in most cases, I'd say that's the right choice. For those of you who need better performance, you can simply write your own routine.

Just my 2 cents.