Software Performance Troubleshooting

With processors getting faster and memory cheaper, it sometimes comes as a surprise to developers when performance objectives cannot be met.

As a neutral third party we can review an existing design or implementation to analyze the reasons behind performance problems and advise on the actions that may be taken to improve it.

Projects we have worked on in the past include:

• Where are my reports? A program was running too slowly. So slowly that users were terminating the program rather than waiting for it to reach a conclusion. Analysis of the program revealed that the programmer had coded a textbook algorithm which, although it would perform reasonably in the average case, had abysmal worst case behavior. Unfortunately the worst case could be expected to occur very frequently indeed. We adapted a library routine to replace the naive coding. The final result was substantially faster, smaller, and more maintainable than the original code.
• Just too slow. Simply upgrading hardware to solve performance problems just does not work in the shrink-wrapped software market. A product used MFC library functions to store its data, exhibiting disastrous performance when the amount of virtual memory used exceeded the physical memory in the machine. We redesigned the data structures to (a) fit expected usage, and (b) degrade gracefully when physical memory was exhausted. The resulting code ran 10 times faster when sufficient physical memory was available, and over 6000 times faster when physical memory was exhausted.
• From batch to interactive. An AI-based product took over twenty minutes to process a small dataset. A careful examination of the algorithm and a review of "prior art" identified possibilities for tremendous improvements both in accuracy and performance. A subsequent implementation, using the algorithms we had identified, proved capable of producing superior results in two seconds. This turned the product from a batch tool into an interactive one, leading to significant changes in the way it could be used and marketed.
• Too unreliable. The parsing component of a software product was giving persistent problems. Analysis revealed that the parser had been written by someone unfamiliar with parsing techniques: the result was software which was both highly unreliable and highly inefficient. We advised (and undertook) a complete rewrite of the component in question. The result was substantial improvements in both robustness and efficiency.

[Back to Services]

Albion Research Ltd. is based in Ottawa, Canada. Please contact us for more information about our services.

© Albion Research Ltd. 2008