Fixing the Issue that Does Not Exist


I spent some time planning on improvements that I wanted to do on one of our project. I reviewed the code that I notice a place where I think I could improve the performance by avoiding locking.

So I wrote the code, and tested it, works great, the new non-locking algorithm works fine. Then when I replaced the old code with my new code and ran my test, to my surprise, it did not behave the way I want it to be. Still works, but the performance and the throughput was not any better. In some cases, it actually yield worse performance compared with the old code.

Curious, I captured the performance counters by running my test app side by side, the one with old code, and the other one with new code.

Look and behold, under extreme cases, the old code has zero Total # of Contentions. The new code, of course has zero Total # of Contentions, and at the same time, consumes more memory due to the lock free algorithm implementation that I chose.

Basically, the lock free code tries to solve a problem that did not exist in the old code. Yes, it uses lock, but the old code runs really fast, and it is very tight, so there was no contention.

Moral of the story, reviewing the code may reveal some issue, put it to test, and verify that the issue is really an issue, before planning any work on it. One good thing, I did not spend too much time on it. 🙂

Skip to main content