What can you do once you determine you have a processor bottleneck? The answer depends partly on the context.
You can try to fix the application, using the tools we discuss in Chapter 10. Let's assume you've already done this.
If you have an 386 processor, you can upgrade the computer to one with a 486, Pentium, or RISC processor.
Assuming you have at least a 486, if you are in a server environment, part of your problem may be the network or disk adapter cards you have chosen. 8-bit cards use more processor time than 16-bit or 32-bit cards. The number of bits here refers to the amount of data moved to memory from the adapter on each transfer. The most efficient cards use 32-bit transfers to adapter memory or direct memory access (DMA) to move their data. Adapters that don't use memory-mapped buffers or DMA must use processor instructions to move data, and that makes the processor busy. DMA uses the memory, and that can slow the processor down, but it is still more efficient than individual instructions. Also, some inexpensive disk controllers do not support DMA.
If you have fixed the adapters and you still have a problem, you might be able to increase the processor clock speed. One method is to multiply the processor clock speed while leaving the rest of the memory and I/O bus speeds alone. Clock doubler and tripler processors do this. This can be very beneficial, although the results in practice are usually less than the multiplier, because real applications do more than just use the processor.
Another thing you can do is increase the size of your secondary cache. Many computers accept a range of secondary cache sizes, and those that do so seldom ship with the maximum installed.
Adding memory without upgrading the secondary cache size sometimes degrades processor performance. This is because the secondary cache now has to map the larger memory space, usually resulting in lowered hit rates in the cache. This slows down processor-bound programs because they are scattered more widely in memory after memory has been added. If you suspect such a slowdown, create a processor-bound test with Response Probe that touches a lot of memory, but fits in the original memory size without sustained paging. Run this test before and after adding the memory, and you may well see that the test is slower with more memory. Disable the secondary cache using the BIOS setup utility, and repeat the experiment with both memory sizes. They should now perform the same. If they do, you have isolated the problem to the secondary cache design.
Finally, you might benefit from adding additional processors. This will help only if you have a bottleneck involving more than one thread capable of asynchronous execution. To the extent that threads can execute in parallel, adding processors provides relief.