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: 1436 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: 6966 Location: porcelain throne
|
|
|
|
If by comp you mean binary, you are wrong.
comp-3, packed-decimal, 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 packed-decimal 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
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 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 packed-decimal 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 packed-decimal 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
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 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: 148 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 COMP-3 (also called PACKED-DECIMAL)?
Using 1 to 9 digits DISPLAY is 60% to 95% slower than COMP-3.
Using 10 to 18 digits DISPLAY is 100% to 180% slower than COMP-3.
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.
<end-paste>
So COMP appears to be faster than COMP-3. And COMP-3 is faster than DISPLAY. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 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 |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 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/COMP-3/DISPLAY Arithmetic
***********************************************************************
On the IBM mainframes, COMP is much faster than COMP-3 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 (COMP-3) compared to binary (COMP or COMP-4) 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 (COMP-3) compared to binary (COMP or COMP-4) 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 (COMP-3) compared to binary (COMP or COMP-4) with TRUNC(BIN) or COMP-5
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 COMP-4) 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 COMP-4) 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 COMP-4) with TRUNC(BIN) or COMP-5
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 |
|
|
|