Ted MacNEIL wrote:
Thanks to all for your thoughts.
And especially to David for doing a quick test for me.

I honestly cannot believe that people are still 'optimising' CPU.

Unless you call major chunks of CPU-intensive code, you are not going to find 
enough savings to buy a beer.

An over-generalization that is definitely not true.

Every language seems to have some features that can be expensive if mis-used. Whether this is critical or not in a particular program all depends on the application. If the application only burns several CPU seconds per month, then obviously this is a non issue, and spending extra time on optimization is wasted. (But since you never know when and where "bad" code may get cloned, to do something poorly when it takes minimal extra time to do it right is also un-professional).

Does it ever make sense to tune CPU time for a program that only uses uses a few milliseconds of CPU? If it's part of an online transaction that executes several million times per day you better believe it! Especially if this is a transaction that runs during prime time when CPU resources are tight. Especially now that many have found that MVS is cheaper when you license it by the peak 4-hour CPU MSU average instead of by total hardware MSUs, failure to tune major CPU users that run during peak hours ends up costing additional real money on software licensing fees.

Perhaps there are companies that never question whether additional hardware and/or higher software fees can be justified. Ours isn't one of them.

For time-critical and cost-critical applications you would certainly want to start by eliminating unnecessary I/O and badly formulated queries. That will most likely reduce CPU significantly as well, but in many cases that may still not get the response time and costs down to where the end-user is satisfied, and you've got to dig deeper and eliminate other code inefficiencies.

Faster processors may resolve response time issues for untuned applications, but on MVS the peak MSU's consumed by the application still drive software costs and are still relevant.

I/O, even with today's faster hardware, is where you should be concentrating.
Especially, on non-Mainframes.
-
Too busy driving to stop for gas!
...


--
Joel C. Ewing, Fort Smith, AR        [EMAIL PROTECTED]

----------------------------------------------------------------------
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

Reply via email to