Re[2]: Date * 10000.01

["Eric DeLong"<eric.delong@xxxxxxxxxxxxxxxxx>]

     No and no.
     
     As I recall, the actual overhead come in when truncating the 
     arithmetic result into a smaller field. If you look at what's 
     happening, you can see the inefficiency.
     
     12311995 x 10000.0001 = 123119951231.1995 
     
     then move the result into a numeric field 8.0. Remember, when 
     moving numeric to numeric, the fields have to realign by decimal 
     point, then the values are cast into the result field. That's quite 
     a bit of work the program has to accomplish just to truncate a 
     large result into a smaller field. 
     
     eric.delong@pmsi-services.com


______________________________ Reply Separator _________________________________
Subject: Re: Date * 10000.01 
Author:  <MIDRANGE-L@midrange.com > at INET_WACO
Date:    11/18/98 3:24 PM


> I strongly agree with Hans.  We did specific performance testing on this
> function in RPG III, and found it to be 48 times more expensive from a CPU
> perspective.
>
> Al

Does this mean that 400 has some extremely weak mathematical processing, or 
is it just the compiler that is badly written?
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---



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