Robert Sample wrote:The z13 has a cycle time of 192 picoseconds, I was reading the other day. Your CPU optimization will have to find a way to dramatically reduce the CPU usage in order to make any noticeable difference. These days, I recommend -- unless there is a known performance issue such as batch jobs not completing in the batch windows -- do not worry about CPU optimization as you'll spend more money worrying about it than you are likely to save.
Don't be too sure about that. Back in 1990 (for an IBM 3090) I showed some code to a friend. "You can cut an instruction or two from this loop," he said. "Nah," I thought, "I'll never see the difference." But I went ahead and cut the instruction, and, yes, I did see a difference. Not much, but it was there.
Where you can see a huge difference is when you change methods. Many of my applications allocate lots of little storage extents using MVS GETMAIN, and frees them, one at a time, using MVS FREEMAIN at the end. I instrumented one of my programs, and was horrified to find out how long the FREEMAIN section took when I fed my program humongous amounts of data. I think I know why FREEMAIN is so slow; in theory I could change the order the FREEMAINs were done, which would improve its performance, but there was another option.
Years ago I had written a private storage manager that was designed to address this problem. But in a way it was difficult to use, and, with smaller chains it didn't seem to make much difference, so it just gathered dust for many years. I dusted it off and put it in the instrumented program. It changed many CPU seconds to a tiny fraction of a CPU second!
The moral of my case study: before you start to optimize, know what you have to optimize.