Performing the Optimizations

The section Analyzing Target Areas helped you determine which software parts of a plagued system to optimize and whom to select for doing the optimizations. This section examines actual implementation issues of performing those optimizations. As such, it is a detailed addition to step 3 in our optimization process, Performing the Design and Implementation of the (selected) Optimizations. This section still has a theoretical focus. It marks the end of the first part of this book. The second part of the book focuses more on programming examples of implementation issues.

After you select a portion of a program to optimize, and before you actually change program code, it is necessary to decide whether to rewrite the existing functionality or to replace it. As mentioned in the previous section, this decision is best made by the architect, perhaps even in conjunction with the project leader.

Replacing Existing Functionality

When you decide to replace parts of a program that either perform poorly or are too large, you basically have two options:

• The replacement part is an existing piece of software.

• The replacement part is designed and implemented from scratch.

It is of course possible to mix these two options, combining existing code and new code. This section describes both cases in their pure forms. Mixed combinations will generally have mixed characteristics.

Using Existing Software

It may be possible for you to find a fully functional replacement part, either in-house (perhaps as part of another project) or from a third-party company. For example, with a slow memory manager, consider replacing it with an existing memory manager that is better equipped to handle the specific dynamic characteristics of your system. Similarly, when you have problems with the data your system needs to handle, consider buying a database management system (DBMS) from a company that specializes in building DBMSs. Of course, there are pros and cons to consider when choosing to use existing software.

Pros of using existing software include

• It does not need to be designed or implemented.

• It has already been tested and might even have proven itself in the field.

• The complete development cost of the software does not have to be assigned to the project budget, only the acquisition costs.

• Problems with the existing software do not have to be solved within the project. (This can also be a liability, as shown in the next list.)

The preceding list shows that using existing software means less development time and more certainty regarding the quality of the software. However, we have yet to look at the cons.

Cons of using existing software include

• Unless your contract with the provider of the software specifically states so, you have no control over updates to the existing software. This means that when a bug is found in the purchased module(s), you can only report it and hope it will be fixed before you have to deliver your system to your client.

• The existing software will have to be integrated into your system. This can mean that changes to interfaces, and even glue layers, are needed. Every extra indirection incurred when using third-party functionality uses up some the performance you are trying to win.

• The existing software was almost certainly written based on different requirements than those specified for the part you are replacing. This can mean a certain mismatch or difference of focus where parts of the functionality are concerned.

• There is always the danger that development on that software will be discontinued some time in the future when the provider of the software is a third party. This can be a disaster when you expect to need support on the software or updated versions.

When the sources of the software become available to the project, this can soften many of the cons. Also, for some static parts of the system, future support might be unnecessary. Simply taking the offered functionality "as is" might do. Often, however, you might not even have the luxury to make a decision. When your requirements are too specific to find third-party solutions, or when existing solutions are too costly to acquire or incorporate, it's necessary to just do the work in the project itself.

Designing and Implementing from Scratch

Consider the following pros and cons when building the replacement part from scratch.

Pros of writing new software for replacement include

• Using the results from the previous solution, you have more information to compare and measure against so that in early stages it's apparent if the new solution is on the right track.

• Because you write everything yourself, you can tweak and tune the new design and implementation to fit your purposes perfectly.

• Wherever the new design calls for changes to interfaces, no glue will be needed. You can adjust both sides of all interfaces.

• Future changes to your system (requirements changes, functional updates, and so on) can be handled internally in the project. When new versions need to be made, it is unnecessary to request third parties to make changes to certain parts of your system.

• No copyright issues need to be settled. This means you do not have to charge your client for using third-party components.

The preceding list shows that the main advantage of building in-house replacement parts is the control you have over the different facets of development.

Although the cons of rewriting system parts are fairly straightforward, they are included here for completeness.

Cons of writing replacement software from scratch include

• Designing and implementing new software will take time.

• New software will mean more testing and perhaps even new bugs. Again, this will take up development time.

• You do not know with a great amount of certainty how much performance or footprint size you will actually win with this new code. You can make estimations, but you are dealing with a part of the program that has previously produced problems with predictability.

This list shows that rewriting software parts negatively affects development time without giving any real assurances about results. Comparing the four lists on replacing software parts, it's logical to replace with existing software when

• A replacement of sufficient—and known—quality can be found. When specific performance or footprint data is missing, some time needs to be spent on evaluating the software.

• Your targets for maintainability of the replacement software can be met.

• There is not enough time or resources to rewrite the software internally in the project.

In all other cases, it makes more sense to do optimizations within the project.

Tuning Existing Software

This section focuses on the parts that need to be fine-tuned to gain increased performance and footprint results. Because these problems are not caused by design flaws as such, but rather faulty algorithms and bugs, the implementers will probably be doing the work in this step on their own.

Some typical examples of performance and footprint tuning problems found are

• Coding bugs

• Inefficient algorithms and processing methods (too few stop clauses for loops and switches, inappropriate allocation time and place for variable memory, and so on)

• Inappropriate use of inline functions (for more detailed information on efficient use of inline functions, see Chapter 8, "Functions")

• Inappropriate use of macros (for more detailed information an efficient use of macros, see Chapter 8)

• Incorrect use of compiler settings, or using compiler settings that are not optimal for the specific module characteristics (for more detailed information on compiler settings, see Chapter 4)

The debugger and the profiler are invaluable tools when tuning software, and they are discussed in detail in Chapter 4. Not only do these tools assist the developer in finding bugs by allowing program actions to be monitored as they are executed, but they also give more insight into which parts of the program use excessive amounts of CPU cycles. So it is easier for you to find problematic lines of code. After you create a list of implementation problems, spend some time "playing" with the system. Make small changes to the different parts of the code to assess the benefits or side effects that might occur. Frequently, this is the first time the implementer takes a good look at the code purely from a performance/footprint viewpoint and the implications of interdependency of different parts of the code. Moreover, this is the time to note the interaction between hardware, software, and tools. Taking this "play" time should provide the addition of more quantifiable information, such as shown here:

• Time needed to solve a specific problem

• Dangers of side effects while solving a specific problem

• Benefits to be gained by solving a specific problem

• Impact of solving a specific problem for different parts of the system

The focus here is on the specific implementation areas, rather than overall system design. However, note that the final item listed provides a brief look at the overall picture. This is necessary because it eliminates useless benefits to lesser or unused portions of your system, or those which are less time-critical than others. Now your choice should be fairly straightforward—which problems to solve and in what order? You should be able to maximize the visible benefits within the allotted time. One final remark on tuning software: After changing the code, repeat any and all tests! It has been stated before, but it simply cannot be stated too often. Practical experience teaches that, often, only tests that seem directly related to the changes that have been made are performed.