It is not always the CPU
Before you start to actually profile your application, you do not know what the bottleneck is. It is not uncommon to see people trying to “optimize” code and save CPU cycles in places were it is not really required. This leads to obfuscated code that is less easy to maintain without a real performance benefit.
I've once read an article that claimed that “it”, meaning the bottleneck is not the CPU period. However, I don’t like generalizations. This one has too many exceptions to be considered the rule. Today I want to discuss one of the cases were it is not the CPU.
In multi-threaded server application one of the possible reasons for low performance is lock contention – a situation in which there’s a resource that is protected from concurrent access via a synchronization object (semaphore, mutex, critical section, etc.) and multiple threads attempt to acquire the lock at the same time.
When this happens the application may be spending more time waiting than actually doing any calculation.
So what can you do if you find that your bottleneck is a lock? There are few alternatives to consider.
- Try to avoid holding locks for lengthy operations.
- Consider using interlocked operations.
- Try to avoid locking (See Raymond’s blog for discussion on some of the pitfalls)
- Try using a spin count for critical sections