Re: Expensive op codes

I agree that code clarity and maintainability are usually paramount.  Even if
there were trivial differences sometimes between ADD 1 X and EVAL X = X + 1,
such differences aren't even remotely significant for 99.99...9999% of
applications.  But the difference between "READ + IF" and "READE" (for some
files, depending on the nature of the actual keys in the file (*) ) CAN be
significant.  Knowing a bit about which areas to look at can help on the
occasions where performance does become an issue.

(*) Note that READE outperforms READ + IF in some cases.  I'm not an expert, so
I can't say what the criteria are, but I wouldn't advocate a wholesale switch
from using READE to READ + IF.  You might lose both code simplicity AND
performance.

Date operations are expensive.  I wouldn't ever advocate replacing date
operations with a few lines of overlay manipulation, but I do advocate replacing
a sequence requiring 3 date operations to one requiring only 1 date operation if
the total code has about the same understandability.  If there had been a
version of "find the last day in the month" that didn't require any thinking to
understand the code, I'd say go with that one, but since they all require some
thinking to understand that they work (in the cases where they did work :), we
can consider which ones are faster, especially since we're thinking about
writing a procedure.

If you are writing a general-purpose procedure that will be called by every
application you write, I think you have the responsibility to spend a bit of
extra time to at least consider performance.  When you write the same code
inline, you know whether it's performance critical at the time you write it, so
you can discount performance in some cases.  But when you write a
general-purpose function, you should write it as though it's going to be called
in performance-critical situations, because it probably IS going to be.

How do you know what opcodes are expensive?  Experience.  At the end of this
note, I'll put a little shell that you can use to do rough performance tests.

Just to throw a final spanner in: if A is faster than B today, it isn't
necessarily true tomorrow.  Not so much because A gets slower, but B might get
faster.  So, unless the difference in performance is significant, go with what's
"better" (using criteria like understandability, maintainability, extendability
etc).

Whew  - that's enough of this for a Monday!  :-)
Barbara Morris

Simple shell for doing performance tests.  If you are comparing 2 ways of
doing something, write 2 programs whose only difference is the code within
the loops.  You can also use a single program to see the general cost of
"doing something X times".

Avoid doing anything in the loops that isn't what you are testing.

Call like this: CALL PERFTEST 100
Call it with sufficiently large numbers that a call with 2 * X takes
about twice as long as a call with X.  That way you can be sure you
are measuring what's in the loop and not just the setup stuff.  Normally
you should let it run for at least half a minute to be able to draw any
significance from the results.

When comparing two methods, once you have a good number of iterations,
run the two versions several times each, and take the quickest time for
each.  Any slower times are caused by other demands on the system, and
aren't of interest for comparisons.  (They ARE of interest if you want
to know in general how long a task takes.)

H DATEDIT(*YMD.)
C     *ENTRY        PLIST
C                   PARM                    timesParm        15 5
C                   Z-ADD     timesParm     numTimes         11 0

C                   TIME                    T6_A              6 0
C                   DO        numTimes
 *---- do your thing here - avoid calling another program or
 *---- procedure since the call time will cloud your results
C                   ENDDO
C                   TIME                    T6_B              6 0

C                   EVAL      msg = 'Start = ' + %EDITC(T6_A : 'Y')
C                                 + ' Finish = ' + %EDITC(T6_B : 'Y')
C                   DSPLY                   MSG              50
C                   SETON                                        LR


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---