View previous topic :: :: View next topic

Author 
Message 
ipavan
New User
Joined: 12 Jun 2005 Posts: 28 Location: Hyderabad




I understand that a numeric variable when Declared with COMP usage does have faster processing than a normal declared numeric variable. So why don't we declare all the Numeric variables with COMP. I have observed in one of the program from my client side, there are some 300 numeric variables. out of them 200 are comp. Why didn't the other 100 they haven't declared as comp. The other 100 are not Redefined also.
Please anyone let me know.
Thank you
Pavan 

Back to top 




murmohk1
Senior Member
Joined: 29 Jun 2006 Posts: 1439 Location: Bangalore,India




Pavan,
Quote: 
Why didn't the other 100 they haven't declared as comp. 
It entirely depends on your shop standards and the requirement.
My suggestion is go thru your shop standards documentation (if you have) and also program spec to understand why they have not declared these in comp. 

Back to top 


dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6962 Location: porcelain throne




If by comp you mean binary, you are wrong.
comp3, packeddecimal, arithmetic is handled by both hardware and middleware. Very few businesses have binary numeric input or store their information as binary, calculate there numerics with binary or output there number data as binary.
IBM mainframes perform packeddecimal arithmetic as fast or faster than the dealing with binary numbers due to the combination of conversion to, calculate, and covert back.
Unless you are dealing with pure science applications. 

Back to top 


dick scherrer
Site Director
Joined: 23 Nov 2006 Posts: 19270 Location: Inside the Matrix




Hello,
Quote: 
I understand that a numeric variable when Declared with COMP usage does have faster processing than a normal declared numeric variable 
Your understanding is incorrect.
The packeddecimal machine instructions perform very well (often faster than binary). In addition, if you intend to show the result of a binary calculation as $123,456.99, it has to be converted from binary to packed decimal first because the assembler to punctuate the number requires the input to be in a packeddecimal field. You might not code the move, but it will happen internally. 

Back to top 


saptagiri kintali
New User
Joined: 21 Sep 2007 Posts: 20 Location: chennai




hi,
This usage is purely depends on your requirment.and one more thing by declaring variables as comp variablde we cant accept that variables..and U CANT use these this arithmatic operations..
also...so its depends on ur requirment only.. 

Back to top 


dick scherrer
Site Director
Joined: 23 Nov 2006 Posts: 19270 Location: Inside the Matrix




Hello,
Quote: 
and U CANT use these this arithmatic operations 
Sure you can.
Add, subtract, multiply, divide, etc are all valid with COMP numbers.
Possibly, i've misunderstood what you have posted. 

Back to top 


TG Murphy
Active User
Joined: 23 Mar 2007 Posts: 149 Location: Ottawa Canada




Pasted below are some notes from one of our performance guys...
<paste>
Performance Trivia: Did you know thatâ€¦
Arithmetic using numeric fields defined as DISPLAY is much slower than fields defined as COMP3 (also called PACKEDDECIMAL)?
Using 1 to 9 digits DISPLAY is 60% to 95% slower than COMP3.
Using 10 to 18 digits DISPLAY is 100% to 180% slower than COMP3.
Arithmetic using numeric fields defined as DISPLAY is much, much slower than fields defined as COMP (also called BINARY)?
Using 1 to 5 digits, DISPLAY is 350% to 480% slower than COMP.
Using 6 to 8 digits, DISPLAY is 500% to 570% slower than COMP.
Using 9 to 17 digits, DISPLAY is 300% to 725% slower than COMP.
Using 18 digits, DISPLAY is 10% faster than COMP. Go figure.
<endpaste>
So COMP appears to be faster than COMP3. And COMP3 is faster than DISPLAY. 

Back to top 


dick scherrer
Site Director
Joined: 23 Nov 2006 Posts: 19270 Location: Inside the Matrix




Hello,
For when there arithmetic operations only.
It would be more meaningful if the "performance guy" included the instructions to place the COMP data on a report or a panel after a calculation (i.e. add a to b, move to an edited output field).
Also, once calculated (cost of arithmetic one time), fields are usually placed on panels or reports or files to be downloaded many times.
IMHO, there is a lot more to resource usage than just the resources used to do arithmetic 

Back to top 


enricosorichetti
Global Moderator
Joined: 14 Mar 2007 Posts: 10169 Location: italy




/trivia on
I do not remember where I got the flash,
in a normal commercial application it seems that
only less than 5% of the cpu utilization is for real(true) computations
the 95% of the cpu is used to just move data around
/trivia off 

Back to top 


mmwife
Super Moderator
Joined: 30 May 2003 Posts: 1592




Here's something offered by Bill Klein that may be of help:
Quote: 
***********************************************************************
Performance Comparison of COMP/COMP3/DISPLAY Arithmetic
***********************************************************************
On the IBM mainframes, COMP is much faster than COMP3 up through 9
digits. After 9 digits, COMP fields are processed with a subroutine,
which is very much slower." That is true when TRUNC(OPT) is used.
If, however, TRUNC(BIN) (for example) is used, the following is from
the Enterprise COBOL V3R1 "performance tuning" paper,"Comparing Data
Types" When selecting your data types, it is important to understand
the performance characteristics of them before you use them. Shown
below are some performance considerations of doing several ADDs and
SUBTRACTs on the various data types of the specified precision.
Performance considerations for comparing data types (using ARITH(COMPAT)):
Packed decimal (COMP3) compared to binary (COMP or COMP4) with TRUNC(STD)
using 1 to 9 digits: packed decimal is 30% to 60% slower than binary
using 10 to 17 digits: packed decimal is 55% to 65% faster than binary
using 18 digits: packed decimal is 74% faster than binary Packed
decimal (COMP3) compared to binary (COMP or COMP4) with TRUNC(OPT)
using 1 to 8 digits: packed decimal is 160% to 200% slower than binary
using 9 digits: packed decimal is 60% slower than binary
using 10 to 17 digits: packed decimal is 150 to 180% slower than binary
using 18 digits: packed decimal is 74% faster than binary Packed
decimal (COMP3) compared to binary (COMP or COMP4) with TRUNC(BIN) or COMP5
using 1 to 8 digits: packed decimal is 130% to 200% slower than binary
using 9 digits: packed decimal is 85% slower than binary
using 10 to 18 digits: packed decimal is 88% faster than binary
using 1 to 6 digits: DISPLAY is 100% slower than packed decimal
using 7 to 16 digits: DISPLAY is 40% to 70% slower than packed decimal
using 17 to 18 digits: DISPLAY is 150 to 200% slower than packed decimal
DISPLAY compared to binary (COMP or COMP4) with TRUNC(STD)
using 1 to 8 digits: DISPLAY is 150% slower than binary
using 9 digits: DISPLAY is 125% slower than binary
using 10 to 16 digits: DISPLAY is 20% faster than binary
using 17 digits: DISPLAY is 8% slower than binary
using 18 digits: DISPLAY is 25% faster than binary
DISPLAY compared to binary (COMP or COMP4) with TRUNC(OPT)
using 1 to 8 digits: DISPLAY is 350% slower than binary
using 9 digits: DISPLAY is 225% slower than binary
using 10 to 16 digits: DISPLAY is 380% slower than binary
using 17 digits: DISPLAY is 580% slower than binary
using 18 digits: DISPLAY is 35% faster than binary
DISPLAY compared to binary (COMP or COMP4) with TRUNC(BIN) or COMP5
using 1 to 4 digits: DISPLAY is 400% to 440% slower than binary
using 5 to 9 digits: DISPLAY is 240% to 280% slower than binary
using 10 to 18 digits: DISPLAY is 70% to 80% faster than binary
Bill Klein 


Back to top 


