From specification to final delivery, professional developers constantly aim to build applications that are robust, clean-running and clear of hidden bottlenecks, resource wastage and performance limitations. AQTime is the tool that tells you at any moment during development how your application is doing. Using its comprehensive suite of profilers, developers can measure the health of their applications with unrivaled accuracy.

Profiling vs. testing

AQTime is an integrated profiling toolkit. The purpose of application testing and profiling is to check whether an application, which is being developed, works as it is supposed to and to assist the developers in improving the application. So, you may ask yourself: "What is the difference between a profiler and a test tool?" A test tool (for instance, TestComplete) records what each part of an application does for other parts, and what the entire application does for the user. A profiler traces how the application does what it does. A test tool takes output measurements. In essence, a profiler takes “health & vitality” measurements. Now that we have shown that profiling and testing are two different things, the rest of this documentation will be concerned only with what AQTime does, profiling.

Manual vs. automation

You can certainly profile an application manually, without AQTime. Manual profiling in its most rudimentary form might be to use a stopwatch and system tools to check resources before and after application usage. A more advanced method of manual profiling is to insert code within your application and check the system timer at the start and at the end of a code section, check resources, output routine calls to a log, etc. In fact, without a comprehensive automated profiler like AQTime, this is what you will be forced to do when you are worried about the “health & vitality” of a section of code.

A profiler, on the other hand, tracks and accurately measures performance and memory use during application execution automatically, then displays the results in comparative format. For instance, it might time the start and end of any routine call, and display the results as a percent of total time used by each routine.

What AQTime does

AQTime removes the dangerous guesswork traditionally associated with performance and memory usage optimization. It offers you an easy-to-use and structured way to hunt down and eliminate the cause of bottlenecks as well as memory hogging unsafe code. With AQTime you can be on your way to building applications that perform at their highest possible level - all the time!

AQTime was built with a single key objective - to help you completely understand how your programs perform during execution. AQTime gathers crucial performance and memory allocation information at runtime and delivers it to you in both summarized and detailed form, with all the tools you will need to begin the optimization process - from customized filters and graphical call hierarchies to source code views.

Of course, taking only one kind of profile is not a way of keeping on top of the general health of the application. This is like tracking your health with a balance. A good automatic profiling application will supply several kinds of profilers, and allow you to use any number together or separately, and on varied parts of the application. Better yet, it will let you interactively pin down the crucial information you are looking for, and which may not be where you thought it would be at first.

Not only can a profiler take many kinds of measurements (how often a function is called, time spent in a given unit, events generated, memory leaks, etc.), it can also get these in different ways:

Some of it is totally non-intrusive: the profiler requests before-and-after information from the operating system.
Some of it is practically non-intrusive: modern operating systems switch tasks many times per second. On each task switch, which would equally occur without the profiler being present, the profiler can gather some extremely simple information; what this changes to the task switch is immeasurable; the profiler’s only practical intrusion is that it uses some memory and resources.
Some of it is minimally intrusive: profiling operations are inserted at many spots, but they are inserted through binary instrumentation. That is, once the executable code is loaded into memory, it is modified to add the needed operations. This is better than source-code instrumentation not only for the reasons explained below, but because in binary the profiling points can be positioned more precisely. For instance, a short (but often-called) function may spend most of its time in setup and finalization, that is, before the first line of code and after the last. Instrumenting source cannot profile those parts of it, so it yields highly misleading information.
Some of it is awkwardly intrusive. The processor allows a soft breakpoint operation, which in principle would be the simplest way to call profiler services. So, one variation of binary instrumentation or source code modification (see below) is to insert these “made to order” soft-breakpoint instructions.
Some of it highly intrusive: the profiler requires modification of the source code, so that your profiling source is never your normal-build source. Since this implies thousands of insertions, it has to be done by an automated source-modification tool. The tool will tempt you into “avoiding” the forking by letting it undo the modifications it did. This is worse still - you can never be sure the “cleaned up” source is identical to what you had in the first place. Some people have sworn off automated profilers because of these intrusions.

As you might expect by now, AQTime never, ever modifies source code. In fact, it always uses the least intrusive method to achieve the requested results. However, since you normally expect results to refer to functions or sections of code, most AQTime profiles require that the application be compiled with debugger information, so that code points can be linked to function or unit names.

In addition, AQTime does not use soft breakpoints, with their context switches. The operations added by binary instrumentation are minimal, and run in the same process as the application. It should be noted, however, that binary instrumentation is still instrumentation. The operation may be very quick, but it leaves the processor, with its pipelines and caches, in a somewhat different state than if there had been no instrumentation.

A note about results: many profiles are measures of relative time. In the ordinary world, relative time is time relative to total elapsed time, that is, real time. In profiling generally, it is different. You cannot do anything about the elapsed time spent waiting for user input, except to go without the input. You can somewhat easier go without some system calls, but the fact remains that you cannot improve system code. Therefore, a profiler by default compares profiled times - the times your own code takes to execute. Relative time is time relative to the time taken by all profiled functions.

AQTime, of course, allows you to get profiles for each function taken alone, or including all the calls it makes to other functions (“child calls”). It also allows you to include or exclude time spent calling the system functions. And finally it allows you to profile functions not just relative to one another, as is the usual practice for profilers, but relative to real time, the entire elapsed time of the profile run, that is, including input and output calls.

A hidden but crucial aspect of AQTime is that its architecture is COM-based. This means it can be used as a server by any application (the idl is supplied of course). In fact, it is used for some services (for example, coverage) by SmartBear’s test automation software, TestComplete. More important is that all the parts of AQTime are COM objects. They can be separately plugged in or out. In fact, some of the profilers we will list below are supplied with your installation as separate plug-ins. More will be made available, or are already available on SmartBear’s Web site.

Therefore, each of these profilers is a standalone object; each is built and tuned to its one purpose. We are not talking about surface “features” added to the same basic engine, we are talking about separate, professional-grade profilers. The business of making them easy to understand and run, and of integrating their results together in a flexible format, is left to the User Interface, discussed further down.

The current list of profilers is in a separate topic, AQTime Profilers. You should read that before proceeding - it is the heart of AQTime.

The User Interface’s main tasks are to allow you to:

Specify the application to profile (project).
Choose profilers to run on it.
Filter the profiler results to center on your particular points of concern.
Display the results.
Format reports.

Results can be filtered by time, location, etc. They can also be filtered by the thread in which the event occurred.

There are many display options. Most results can be shown in one or several graphical formats (e.g. histogram), or in a selection of columns.

One display mode for the profiler results deserves special attention: the Call Graph. All binary-instrumented profilers in AQTime can record the caller for each call of a function. The problem is what to do with the resulting data. The Call Graph is a very easily understood, interactive display that shows each profiled function with basic timings, and arrows from the functions that called it, and to those that it called. Each arrow carries the count of calls recorded.

The most controllable form of result display is the report, which is a totally-configurable grid shown in the Report panel. Besides this onscreen display, the Report panel can print its contents and export it to a text, Excel, html or xml files.

Integration into IDEs

AQTime is tightly integrated into Microsoft Visual Studio and Embarcadero RAD Studio. This feature provides you with the full AQTime functionality without leaving the IDE. You can create and manage AQTime projects, profile your applications and view profiling results directly from the IDE. See Development Tools Integration for more information.

Getting Started

To start using AQTime, see the Getting Started topic of this help system.

Introducing AQTime

Profiling vs. testing

Manual vs. automation

What AQTime does

Integration into IDEs

Getting Started

See Also