Five Common Mistakes When Dealing With Performance Issues in Your Application

As a software developer, we will have to deal with performance issues at some or the other point in our software development. I am listing out some of the most common assumptions and mistakes made by developers when dealing with performance issues.

Diagnosing Memory Leakage Issue as Performance Issue

An application's performance can severely degrade if memory consumed by it is not handled properly. If your components are not getting rid of unused memory, your application performance can severely downgrade over time. Even if you’re using run time environment like .NET or JAVA which supports automatic garbage collection, many recommendations are made to make sure that memory is cleaned up properly for your objects and allocations requests to be made in a specific manner to run your application in an optimal way.

Hot Spots Are Not Always the Problem

Many developers when encountered with performance use a profiler tool to identify hot spots in code and try to optimize only those. This is good but you will reach a limit and then on, you will not be able optimize any more. Most of the time, developers will be aware of hot spots in their code and profiler tool may show an unexpected hot spot like an event of a control firing more than (s)he taught which you may find ways to fix. Unless it's the latter case, most of the times, hot spots may not help you beyond a certain point, so you may have to take a step back and look at data structures, collections and algorithms chosen for your applications to see if they are the right choices and do appropriate corrections.

Adding More Threads May Degrade Performance

As soon as a performance issue appears, if memory leakage and hot spots are fixed or ruled out, the default tendency is to find places in your application where things can work in parallel and create threads or use threadpools. This will work most of the time, but going overdrive on number of threads being created or task queued in thread pool then it might start degrading. A healthy size of thread pool or number of threads must be chosen carefully based on target environment where your application is supposed to run. If multiple processors or mulit-core processors are not there, applications which are I/O bound will only benefit from adding threads.

Not Choosing Data Structures or Collections Carefully

The way you choose your data structures to store user and application data can make a huge difference in your application performance, so choosing the right one is very important. Certain algorithms for manipulating your data can be optimized by adding look up fields or additional fields in your data structure. Do consider them if it’s an option as you can reduce a lot of CPU time if cross referencing and looking up data in your data structure is complex. All languages libraries and frameworks provide built-in collections to store data. Be aware of how they are working internally and what's optimal for what situation. Choosing the wrong collection can degrade your application performance severely.

Not Being Careful While Using Third Party Controls or Libraries

Using Third Party libraries can save you a great deal of development time but read the documentation carefully. Many a times, developer look at example programs and build the application and as sample production data is used to test performance, issues tend to surface and might surface late in the development cycle. At times, I noted that upgrading to a newer version of Third Party library can have unexpected results as new performance bugs will get introduced, I had encountered this when an Excel export feature for grid which I was using crashed when upgraded to a newer version as it was not using Fly Weight pattern to keep color objects of a grid causing my application to slow down and crash for large grid sizes as it ran out of memory.