Peter, The answer is: it may not matter. Some time ago I was asked to do research to see if the installation I worked for could justify a COBOL optimizer (this was a while back, but I believe same issues are true today). I gathered SMF records and sorted them down by total CPU consumed by PGM=program name in our installation for a month. The results were very interesting, but I would be also interested to know if others have done this and what they found out.
What I found out was the following: - About 30% of the CPU was consumed by SORT - About 10% of the CPU was consumed by IEBGENER - ... - About 2% of the CPU was consumed by application COBOL programs. The conclusion I drew was that even if you eliminated all of the CPU used by application COBOL programs, the most one would save is 2%. We declined to purchase the product. It has been my personal experience that a similar, but perhaps different CPU profile exists in most shops (that is, a list of declining amounts of CPU time). The products that use large amounts of CPU time are well known, and a great deal of effort at IBM and ISVs has been expended to work on this issue. To verify this, just do the same thing on your particular program for all of the CPU it uses in a month. The small amount may surprise you. Additionally, a portion of the CPU time charged to your program may be in doing services on your behalf, such as QSAM, various SVCs, etc., over which you have some, but often times, little control. Tom Harper IMS Utilities Development Team Neon Enterprise Software Sugar Land, TX -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Farley, Peter x23353 Sent: Tuesday, February 05, 2008 3:39 PM To: [email protected] Subject: Re: CPU time differences for the same job This most interesting discussion of the variability of CPU consumed by the same unit of work requires me to ask the following question: How is the normal application programmer who is tasked with reducing the CPU consumed by an application process (let's say a complex batch process for the sake of argument) supposed to judge whether he has improved the process or not? Granted, there are frequently obvious performance design flaws that will significantly impact CPU consumption (sequential searches on large in-storage tables vs. binary searches for one simple example), but once the obvious performance improvements have been made, how does a normal programmer accurately measure change in the performance of a process when CPU variability may completely mask any effect that source-code changes may or may not have had? More to the point, how does a programmer show management what the improvement will be from a given set of changes when the results may be completely unrepeatable, depending on system load? Application programmers do not (usually) have the luxury of dedicated machines on which to run performance tests. Add to that the fact that test environments for developers infrequently have the same priority as production environments, and so are subject to even more delays and therefore cache-misses, along with all the other performance-killers mentioned in this thread. How can a programmer accurately predict for management approval what the production performance improvement will be when the test environment is so much more poorly served than production? When even successive runs on the same test machine at the same time of day produce large and unexplainable differences in performance? Please correct me if I am wrong, but much of this discussion leads me to believe that we are saying that there is essentially no reasonable way to predict or model performance for a given application process. That just seems so *wrong* to me. Measuring and accurately reporting application performance improvement should NOT require an advanced degree in hardware engineering and being able to design around the impact of missed cache-lines. I am hoping I am wrong about my interpretation of this information. Counter-examples and/or corrections to my understanding of the subject gratefully accepted. Peter ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
