Joe Zitzelberger wrote:
What was hyper-efficient last year might not be today. Many of the
'efficiency' tricks that programmers have used for decades are now
actually hinderances.
Depends on what we're talking about. LA r,0 vs. SLR r,r probably is
irrelevant these days. LA r,0(s) vs. LA r,0(,s) isn't.
And atrocities like LH r,=H'5' rather than LA r,5 are still timely.
My take on the best approach is to first write source that is clear and
understandable by other humans. Then, once it is written and tested,
to use profiling tools to determine where the efficiency concerns
actually are. Usually, they are not where programmers would have
'expected' them to be.
I consulted at a government agency where I found code that's very clear
and easy to understand:
TM flag,1
BZ label
NI flag,255-1
label .....
(As an aside, this program took nearly 24 hours of CPU. We moved two
instructions and caused it to run in two minutes).
Perhaps the underlying root is clarity of mind, or clarity of purpose. I
once wrote some code (about 80 lines) to patch HASP, only to have it
fail if the printer ran out of paper. Later on I found code from
Waterloo to do the same thing, in a different module, consisting of
three lines!
We're in agreement on the profiling, but not on 'unexpected' locations.
Do you have any specifics in mind?
Gerhard Postpischil
Bradford, VT
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
