Hello,
Does anyone know any sites/books/articles covering best practices or theory around design patterns in high performance applications? It seems a lot of the patterns use indirection/abstraction/encapsulation in a way that may affect performance in computationally intensive code. Head First Design Patterns and even GoF mention possibility of performance hits with many of the patterns but without more.. concrete advice on how to deal with it.
Design pattern is really focusing on how you structure the code and define the class abstraction and interaction. Performance of your computational performance will really be mostly effected by the way you write the actual code implementation (body of the method).
For C++ I definitely suggest reading Scott Meyers book on Effective C++ and More Effective C++ series of books which in itself really reveals many idioms on writing high performance code.
Design patterns exist to help you come to grips with how to design software or improve its flexibility. How you implement the pattern determines what kind of performance penalty (or benefit) you will see from its use.
Some patterns do exist because that overall way of structuring things generally does lead to faster programs. But unlike algorithms there is no good way to really formally analyze a pattern to decide on how slow or fast it is.
My advice would be to use a pattern if it helps you figure out how to design a particular piece of code, or if you need to refactor to make code more flexible or clear. If you then have performance issues, use standard profiling techniques to find them.
If you're refactoring when you encounter performance issues, maybe the cost isn't worth the refactor, or maybe there's a way to mitigate it. If you're designing new code, maybe there's a way to mutate things to fix the performance issue if it truly lies in the necessary indirection for the pattern to work.
The most concrete advice is: profile it in your application and see how much of an impact it really makes.
Any other advice is going to be considerably more general and may not necessarily apply well to how you have implemented a given pattern in your application with your compiler on your platform.
You can read Herb Sutter's entries under "Effective Concurrency" for things involving multi-threading and concurrency patterns and how they affect performance.
Design patterns are mostly ways of breaking your program into smaller pieces, which are easier to reuse, compose, design, and test. Several design patterns will result in code that performs worse than a simpler design, but they have a significant advantage when you consider the 80/20 rule.
The 80/20 rule says that 80 percent of your program's execution time will be spent executing 20 percent of it's code. When your program is nice and modular, it's easy to throw it in a profiler and see exactly which component could be tuned/optimized, or where it makes sense to go with a less flexible design in order to improve performance. Having the design that far separated initially though makes it easier to find performance hot spots.
One term that may help you get better hits is 'pattern language'. It's a collection of patterns that go together for some purpose. If you have a more specific goal that high performance someone may have plotted out a path through patterns for your domain, for example: pattern language for parallel software. Here's another nice collection of parallel programming patterns from UIUC, a hotbed of patterns work.
The ACE/TAO guys have a lot of papers about high performance network patterns using C++
I’m surprised we aren’t asking what performance problems you are having!
In my experience, performance problems are usually tied to specific conditions and situations. Design patterns, on the other hand, are solutions to more general and abstract problems. It would seem a bit awkward to approach both in the same text: what of possibly many "non-patterned" solutions should the author compare the performance of a design pattern against? When the performance problem is general, there certainly already are patterns to solve them: the Flyweight is a good example.
The penalties imposed by the use of a design pattern are of a finite, very small set: introduction of virtual calls, added latency due to delegation, extra memory consumption due to the proliferation of objects and so on. If, after profiling, you notice that these are the cause of your woes, there are known ways to minimize them.
Knowing the patterns might be useful to solve performance issues, too. First, someone already mentioned that patterns break down a problem in smaller bits: this might ease pinpointing the source of the issue and isolating ugly but performant code. They also create a framework of reasoning and expectations for developers. If you must introduce a deviation for performance reasons, it will be obvious: “Except here, where we forego X and do Y to improve performance, this is a Chain of Responsibility.” They are rules to be broken when needed.
(Alas, there is one very good pattern for getting good performance: measure, pinpoint, fix.)
GoF design patterns are about using proven patterns to solve common problems with elegant, maintainable code. They don't target performance.
If you want patterns for performance, you may need to look at system architecture patterns, algorithms, data structures, etc.
What does your app do?
If your application is in C++, and is written sensibly, the chances are your code will run blindingly fast on modern hardware, until it has to wait for I/O. The exception would be something like real time image analysis that is very processor intensive.
If performance is an issue, do you really mean I/O performance? (disk, DB, network etc.)
There are 'patterns' that allow your application to perform even while frequently waiting for I/O (asynchronous callbacks etc.)
If you are dealing with an uneven load, whereby the peak load may be much higher than average load, a commonly employed architecture pattern is to de-couple system components with message queues.
Remember the old saying "You can have it good, fast and cheap, pick two"
Design patterns address the good. A good foundation is needed so the code can be accurate, and maintainable.
If performance is an issue, then benchmark and then optimize the sections that give you problems. Many times performance is just a question of picking a proper algorithm., but it may mean you need to break-out into some horrifically optimized code for that 10% that takes up 90% of the time. Just make sure you comment the S^^T out of it.