Common causes of slow performance
The Performance Call Graph and Method Detail views help you identify the parts of your application that consume the most time. You can then investigate whether these time-consuming areas can be made more efficient. When you analyze the code for your application, it is useful to be aware of the most frequent coding errors that result in inefficient performance.
Needless computation: As applications evolve and algorithms are refined, or as data changes, portions of code that were needed in earlier versions can fall out of use, without ever being removed. Because of this, many large programs perform computations whose results are never used. Bottlenecks are caused by time wasted on this dead code.
Other common needless computations are those made automatically or by default, even if they are not required. Applications that needlessly free data structures during a program's shutdown, or open connections to workstations even though there isn't a user for them, are examples of this type of bottleneck. You can profile performance to find the time that is spent in dead code. Once you're convinced that the results of a computation are useless, you can remove the code.
Premature computation: Any computation that is performed before there is a need for its results can cause a bottleneck. For example, there may not be a reason to sort a list of numbers if the user has not requested that the sort be performed. Performance data cannot tell you if the computation can be delayed; however, it can tell you the cost of the computation, and you can decide whether to postpone it.
Needless recomputation: Programs sometimes recompute needed values rather than caching them for later use. For example, determining the length of a constant string can result in needless computation if the computation is embedded in a loop; the length of the string is recomputed many times, each time getting the same value. Your performance data can tell you where the recomputation is taking place, and you can decide to store the value after one computation.
Inefficient computation: A poor choice of algorithm or data structure layout can cause extra work for the program. The initial performance can appear acceptable, given small data sets, but then scale poorly when presented with larger or more complex data sets. Performance profiling can tell you the cost of each computation at different scales so you can predict whether there will be a problem with still larger data sets. You can then use alternative algorithms and data structures that get the job done faster.
Memory leaks and thread bottlenecks can also degrade performance. Use the Leak Detection and Thread Analysis profiling sets to collect data for resolving these problems. Note that you cannot collect leak detection data at the same time as you collect other run-time analysis data.
Parent topic
Viewing and analyzing performance data
Related tasks
Getting information from the Performance Call Graph view
Related reference
The Method Details view
The Performance Call Graph view
Performance Call Graph data commands