RE: Date arithmetic - performance dog?

[Buck Calabro <Buck.Calabro@xxxxxxxxxxxx>]

Michael P wrote:

>I wanted to see if you folks have found that ADDDUR and 
>SUBDUR (etc.), and MOVEing to/from date fields are 
>REALLY poor performers - it sure seems that way to me.  

This is an interesting sort of question.  Is CHAIN slower than READ?  Well,
yes.  But they do different things.  I could emulate CHAIN with READ but it
wouldn't be much fun to maintain.  Likewise, I can emulate date operations
using integers or packed decimals...

Mike H said:
>...someone mentioned they thought they took a 40% performance 
>hit when using date fields and date logic

It made me wonder what the comparison was to, so I wrote a quickie program
to time some very simple operations:

     h debug option(*srcstmt) dftactgrp(*no) actgrp('QILE')
      * dbgview(*list)

     d packed          s             11p 0
     d int             s             10i 0
     d date            s               d
     d start           s               z
     d stop            s               z
     d elapsed         s             10i 0
     d loop            s             10i 0 inz(100000)

      * baseline?
     c                   eval      packed = 0
     c                   time                    start
     c                   do        loop
     c                   add       1             packed
     c                   enddo
     c                   time                    stop
     c     stop          subdur    start         elapsed:*ms
     c     elapsed       dsply

      * fastest?
     c                   eval      int = 0
     c                   time                    start
     c                   do        loop
     c                   add       1             int
     c                   enddo
     c                   time                    stop
     c     stop          subdur    start         elapsed:*ms
     c     elapsed       dsply

      * compare date...
     c                   time                    date
     c                   time                    start
     c                   do        loop
     c                   adddur    1: *d         date
     c                   enddo
     c                   time                    stop
     c     stop          subdur    start         elapsed:*ms
     c     elapsed       dsply

     c                   eval      *inlr = *on

Several runs look similar to this:
call datetiming   
DSPLY       79000 
DSPLY       33000 
DSPLY     7947000 
call datetiming   
DSPLY       93000 
DSPLY       35000 
DSPLY     8434000 
call datetiming   
DSPLY      113000 
DSPLY       33000 
DSPLY     9183000 
call datetiming  
DSPLY       79000
DSPLY       33000
DSPLY     7769000
call datetiming  
DSPLY       79000
DSPLY       33000
DSPLY     7864000
call datetiming  
DSPLY       80000
DSPLY       34000
DSPLY     7876000

523   / 6 = 87.17
201   / 6 = 33.5
49073 / 6 = 8178.83

This is on my 620, V5R2 1gig machine.  If we look at incrementing an integer
as 1x, incrementing a packed field is 2.6x slower and incrementing a date is
244.14x slower.  If you need the date functionality, then you need it, no
matter the runtime cost (like CHAIN over READ.)

OPTIMIZE(*FULL) made very little difference in this test, except to make
integers even faster, about 19ms instead of 33ms per hundred thousand ops.

call datetiming   
DSPLY       59000 
DSPLY       19000 
DSPLY     7895000 
call datetiming   
DSPLY       65000 
DSPLY       19000 
DSPLY     7848000 
call datetiming   
DSPLY       97000 
DSPLY       19000 
DSPLY     8192000 
call datetiming  
DSPLY       59000
DSPLY       19000
DSPLY     8220000
call datetiming  
DSPLY       96000
DSPLY       20000
DSPLY     9929000
call datetiming  
DSPLY       59000
DSPLY       19000
DSPLY     7866000

So on my box, incrementing a date costs about 82ms each.

  --buck