Tuesday, January 20, 2015

Software Performance Improvement

Whenever anybody asks me to improve performance of any software, typically, I say I cannot do it.

But, what I do is,

Clean the dirty code.
Remove the redundant code.
Refactor at method level to make it more clean and simple.
Refactor at class level to make it more clean and simple.
Make the design more clean and simple.
Change the design to make it more simple.

If this improves the performance, then well and good. After all this, if the performance is still not improved to the expectation, then I would say, this is the limit. If you want better performance, get better hardware or get more servers.

For performance improvement, if anybody does any of the following, I try my best to stop them from doing it.

Any change to the code/design which reduces the simplicity of the code/design. This is one of the biggest grey areas and it is mainly trade-off. How much are we ready to sacrifice the simplicity/cleanliness of the code for how much performance. Typically, I am always on the extreme side of clean code/design.

To improve the performance of some functionality, which is there in the performance test suite, reducing the performance of other features which are not there in the test suite.

Not caring about the functionality which is having very bad performance, since it is not there in the performance suite, and caring about only the features that are there in the performance suite to improve the numbers.

If anybody gives me clean code with clean design, and asks me to improve the performance, then they would say that, I am the most incompetent developer that they have ever seen.

No comments:

Post a Comment