Profilers yield a mass of information. The trick in using them is to ask only for the kind of information you need at the moment, get it, then start over again, using what you have just learned to refine the question you are asking. In other words, you dig down progressively.

Therefore, even more important than what information a profiler can provide is how easily it will focus on what you want to know. A good profiling tool is one that you can ask very restricted questions easily, get answers, then re-tune your question. Otherwise, the important information gets lost in the mass of results which, at the present moment, are of no importance or, worse, a distraction. (In addition, a few profilers seriously add to execution time, so you do not want to wait while they gather information you won’t need).

A lot of the advantages of AQTime reside in the ease of use, variety and flexibility of the means it provides you with for controlling what gets profiled in any given run. All of them work on the exclusion principle: if a given means says something will not be profiled, it will not be. If it does not say that, or it says the code “will” be profiled, then the code will only actually be profiled if all the other means permit. From the very general to the very local, these means group into the following categories:

Filter non-modifiable code. Many development environments include a number of their libraries in your application. For example, Borland Delphi IDE typically embeds System, Classes, Controls and other units. Generally, the source code of these libraries cannot be modified, so their performance cannot be improved. Therefore, you should focus only on those elements that you can change. To filter out modules provided by standard libraries, you can use AQTime’s Exclude standard source files option. The option can also be enabled via the Exclude Standard Source Files button located on the Setup panel.

Note: This option is supported only for native (unmanaged) and .NET applications.

You can also specify code that will “never” be profiled using other options. For more information about them, see Excluding Code From Profiling.
Define code areas to profile. Areas are a central concept in AQTime. Any number of files, classes or routines can be included in an area, and any number of areas can be checked (or unchecked) for profiling in a given run. Furthermore, each element in a checked area can also be checked or unchecked. Areas are a primary tool for progressive refining of what you want to profile. As noted, code correctly checked-in this way only gets profiled if all of the other means permit it. But what is not checked does not get profiled on this run, period. Because sometimes you may want to put an entire class or namespace in an area, except one or two elements, in addition to the normal including areas there are excluding areas. Since nothing gets profiled if it is not in an including area, the point of excluding areas is only this, to provide an easy way of removing certain sub-elements from a larger element added to an including area. See Using Areas.
Define when to profile your code. Triggers are another central concept in AQTime. They apply only to the Performance, Function Trace and Coverage profilers and they let you control profiling on a thread by thread basis. There are on-triggers and off-triggers. An on-trigger is a routine that turns profiling on when it begins and turns it off (unless another trigger is running) when it ends. Code that is correctly checked in the area system, and not excluded as a “system file”, will be profiled only when it is called from a trigger routine in the same thread, directly or indirectly. Off-triggers are the opposite. While they are running, whatever profiling would be going on in their thread is turned off. If there are no trigger routines, then profiling is always on by default (the application is the trigger). See Using Triggers
Turn profiling on and off during the run. The Enable/Disable Profiling toolbar buttonThe AQTime > Enable/Disable Profiling menu itemThe AQTime > Enable/Disable Profiling menu item can turn profiling off at any time while the application is running. When it is “on” (the default), profiling is enabled (of course, it is enabled only if no off-trigger or action is active). When this button is not pressed, the profiling is off. This is a really quick, no-fuss, no-mess way to restrict profiling to a given trouble spot -- once you know where it occurs. Its drawback is that you can never repeat the run exactly; for run-to-run comparisons, actions or triggers are the tools to use.
Perform specific operations during the run: actions. An action is a routine, before or after execution of which AQTime can perform a specific operation like switching the profiling on or off or getting the profiler results. Actions are similar to pressing the Enable/Disable Profiling or the Get Results toolbar items from the application code. But unlike manual pressing, actions allow you to press these items exactly when you need it. For more information on actions and differences between triggers and actions, see Using Actions.
Collect a stack for specific modules, classes and methods. AQTime lets you select which modules, classes and methods are included in the stack collected at run time. This allows you to decrease the size of the stack, as it does not contain unnecessary calls to third-party and system functions. To specify the desired elements to be included in the stack, use the Collect Stack Information Pane of the Setup panel. The pane is shown only if you select either the Allocation, Resource, Reference Count or Failure Emulator profiler. For more information on defining which stack areas are included into the collected stack, see Specifying Modules to Be Included Into the Call Stack.

3. Choosing What to Profile and When

See Also