Practice7.Don t Neglect Performance

Practice 7. Don't Neglect Performance

Performance is one topic that generates passionate discussions in software development. Some people feel that code clarity is more important and that you should get the code clarity right first and then optimize the 1 to 3 percent of code that needs it. Others feel that you should code for performance first, because if you don't, your code will always be slow.

Personally, I get scared when a development team or developer says "we'll worry about performance later." I have seen too many projects where the team felt the need to get the features in before worrying about performance led to months or years of rework. Code clarity does come first, but not at the expense of performance. This is another case where you need to embrace the genius of the AND: You must be concerned with performance AND clarity, with a strong bias toward the latter. You don't have to be obsessive about performance, but you need to understand what the customer's expectations are, design for the right level of performance from the beginning and where performance really matters, ensure that you have tests to measure performance and let you know when the performance degrades in a noticeable way (see Chapter 5 for more on performance tests). You should never have to hear from your customers that your product is too slow…!

I also get scared when a development team says its software will get faster on the next generation of hardware. The fact that computers are getting faster is a constant and everyone benefits, including your competitors. Applications are also getting larger and more complex. You need to understand at least the basics of performance for the programming language and framework your product works in. Just because you develop in Java, for example, doesn't mean that you can neglect performance, even though Java is an interpreted language.

Data Structures and Performance

Sometimes, even the simplest things like data structures can have a huge performance impact. For example, I once worked on a product where the code was copying three large arrays into a single buffer. One day we noticed that all of a sudden the application had gotten a lot slower. After profiling the code performance, we discovered that the size of the three arrays had been increased just enough so that they were each larger than the CPU's primary memory cache. Hence, every time one of the arrays was used (i.e., every byte) the CPU flushed its cache to make room for the new array. The solution was to use a single array, which could be quickly streamed into the CPU's memory cache by the hardware and then accessed much faster.