Code Optimisation

 In blog, Code Quality

Imagine its Friday evening, you are having long weekend plans and about to pack your bag and head home and suddenly you get the issue on production. Something has been broken and all evidence points to an application performance bottleneck.

So question leads to how can we prevent performance issues from reaching to production environment?

That leads us to optimisation and fine tuning your code so that you can guarantee 0% downtime for your application.

Here are the few of the points from my experience that can help you optimize your code.

Boxing and Unboxing

Boxing and unboxing is rather an expensive process in terms of computation. So if you use it in array of list, the cost of boxing and unboxing goes high to the number of times the entities in list or array. When a value type is boxed, an entirely new object must be created. This can take up to 20 times longer than a simple reference assignment. When unboxing, the casting process can take four times as long as an assignment. [1]

Strings

String concatenate is a very common thing possibly every developer do day in, day out but possibly you are doing It all wrong.

If you are using string concatenate with large number of variables or loop, instead of using “+” operator or  Concatenation Operators use use System.Text.StringBuilder. [2]

Loops

Instead of using foreach use for loop. Now you may wonder what is wrong with foreach, there is nothing wrong with foreach but few points of it makes it more expensive in terms of memory and computation power.

  1. In terms of a variable declaration, foreach loop has five variable declarations whereas for loop only have three variable declarations.
  2. The foreach loop copies the array and put this copy into the new array for operation. Whereas for loop does not do. [3]

Exception Handling with loop

Instead of putting try / catch block inside of loop, Surround the entire loop inside of try / catch block.[4]

Exceptions 

While adding try/catch is cheap, throwing an exception is expensive. For example, checking if something can be parsed by calling int.Parse() and catching an exception should be avoided. Instead, you can use int.TryParse() which return false If parsing is impossible.

Reflection 

In .NET is a very powerful, but expensive. Avoid reflection as much as possible. Operations like Activator.CreateInstance() and myType.GetMethod("Foo").Invoke() will hurt performance. So use it wisely where it is really required.

Datatype

dynamic type is really expensive, try avoiding it entirely if possible.


Multi-threaded synchronisation

It is hard to get right. If there are locks and threads waiting on each other, there is a potential performance problem in your code, along with the possibility of deadlocks. If possible, try to avoid this altogether.

Conclusion

Ultimately, I would like to end it with the law of instrument.

“The law of the instrument, otherwise known as Maslow’s hammer, is a cognitive bias that involves an over-reliance on a familiar tool.”

A hammer is not the most appropriate tool for every purpose. Yet a person with only a hammer is likely to try and fix everything using their hammer. often without even considering other options. We prefer to make do with what we have rather than looking for a better alternative.

So for conclusion, a hammer is a great tool, but you cannot treat every problem as a nail. Use your brain and select appropriate tool for the problem at hand.

Recent Posts

Leave a Comment

Start typing and press Enter to search