As a software developer we will have to deal with performance issues at some or other point in our software development. I am listing out some of the most common assumption and mistakes made by developers when dealing with performance issues.
- Diagnosing Memory leakage issue as Performance Issue An Applications performance can severely degrade if memory consumed by its not handled properly. If your components are not getting rid of unused memory your application performance can severely down grade over time. Even if you’re using run time environment like .NET or JAVA which support 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 specific manner to run your application in optimal way.
- Hot spots are not always the problem Many developers when encountered with performance use a profiler tool 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 time developer will be aware of hot spots in his code and profiler tool may show an unexpected hot stop 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 are they right choices and do appropriate corrections.
- Adding more threads may degrade performance As soon as 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 times 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 multi-core processors are not there only 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 huge difference in your application performance, so choosing right one is very important. Certain algorithms for manipulating your data can be optimized by adding look up fields or additional fields in you data structure, do consider them if it’s an option as you can reduce lot of CPU time if cross referencing and looking up data in your data structure is complex. All languages libraries and framework provide built-in collections to store data be aware of how they are working internally and whats optimal for what situations 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 great deal of development time but read the documentation carefully many at time 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 development cycle. At times I noted that upgrading to 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 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.
gauthamprabhuk 