I quite often find that I never optimize my code at all and I can be working on extremely high performant systems and the reason is that the code is clean, Martin Thompson stated at the recent DDD Exchange conference in London.
Martin, working in the high performance space, has worked on some of the largest catalogue systems and highest transaction throughput systems in the world with up to 10ths of millions of events per second and contrary to the common belief that extremely high performance code must be ugly, obscure and hard to read, his experience is that performance is about clean and representative models, it’s only a single digit number how much time you spend actually doing performance optimizations.
Two main concepts for Martin are clean and representative, concepts which he thinks also aligns well with what DDD stands for at its core. A clean model is uncontaminated containing only the language in use and data structure. If technology is present, like Spring or an ORM, it will make performance a real issue as well as causing problems with maintenance and evolving the model. Representative is the portrayal of the real world. Models are at their best when they are a capturing of our understanding of the domain we are working with, a living model of the problem addressed.
For extremely high performant systems considering the internals of a server and the CPU may be very important and Martin describes how different the time for executing code can be depending on where data is found; in one of the local caches or in physical memory. Moving from a local cache out to e.g. memory will mean a much higher latency.
Martin gives a number of tips for model implementation that he has found being important for performance, including:
- Respect locality of reference, a key to performance. Cohesive bounded contexts is very relevant, with very clear and a minimum of communication between them. Martin states that good design principals are fractal; they will work in the small as well as in the large.
- Make data structures your friends, forget the entities and focus on the associations between them.
- Batching is great for online. Multiple threads working on the same resource may have some nasty queuing effects, by intermediating this with a queue and a batcher the throughput can increase substantially.
- Abstractions. Martin’s first rule is to not use abstractions, they have too high cost. He thinks we abstract far too soon, instead we should copy and consider abstraction only when we are really sure it’s the same thing.
Martin finally emphasizes the need for performance testing as part of the continuous integration and closes his presentation with:
When models looks good and elegant they tend to always perform well
Next year’s DDD Exchange is scheduled for 19th June 2015 and registration is open.