The Static Analysis profiler analyzes debug information (native applications) or metadata (.NET-connected applications) that is included in profiled applications. It collects data on the application’s code and determines what methods and classes are used in the application and how they are interconnected.
The Static Analysis profiler supports both 32-bit and 64-bit applications.
The following sections provide detailed information about the Static Analysis profiler.
The Static Profiler, as the word “static” indicates, does not launch the profiled application. When you start profiling, the Static Analysis profiler checks the modules included in the current AQTime project. Note that you cannot set areas or triggers for this profiler.
The profiler collects information on:
The size of the routines in bytes.
Their length in source code lines.
The routine addresses in memory.
The structure of method calls as written in the source code.
The binary code generated for the routine.
The number of binary instructions in the routine.
The number of loop instructions in the routine.
The number of exception handling frames in the routine.
The number of conditional operators in the routine.
The number of floating point operators in the routine.
And so forth.
In addition, the Static Analysis finds all of the potential interlinks of your application’s classes through their methods, that is, the links in all possible code branches. Therefore, the Static Analysis Profiler centers on both methods (routines) and class interlinks.
You can use the data collected by the Static Analysis profiler to answer the following questions:
What code is used by an application? If the application includes a massive module only to use one or two functions from it, you might choose to extract them from the module, or to re-implement them so as to save on application size and dependencies.
Which routine is located by a certain address? For instance, if the application raises an exception, you can launch Static Analysis and determine from the exception address reported which routine caused it.
What binary code was produced by the compiler for a routine? This can tell you for instance if array or string parameters are being passed by copying the data to the stack, or only a pointer.
What functions and procedures are called by a routine? This tells you what methods are called or (more exactly) can be called from other methods.
Is a routine overburdened with too many loops, conditional jumps, exception handling frames and other code structures that may impede the routine’s performance? Such routines are potential candidates to be rewritten.
What classes exist in the application, what methods they have, which methods of other classes call methods of the given class or are called by this class's methods (in source code, independent of whether the call is ever executed).