During the lifetime of software applications, it is not uncommon to investigate application tasks that are determined to be performing slower than expected. You might also simply want to know what is going on when you 'press this button'! You can work this out quite quickly in Enterprise Architect by using its Profiler. Results can usually be produced in a few seconds and you will quickly be able to see the actions that are consuming the application and the functions involved. In the Execution Analyzer, The feature employs two separate strategies; Process Sampling and Process Hooking. In one, samples are taken at regular intervals to identify CPU-intensive patterns, while in the other, the process is hooked to record demands made on memory. Data is analyzed to produce a weighted Call Graph. Behaviors are usually identifiable as root nodes (entrypoints) in the graph, or branches near these points. All reports can be reviewed on demand. They can be saved to file within the model, both as Artifact elements and as Team Library posts.
Execute > Analyze > Profiler
Execution Analyzer toolbar : Analyzer Windows | Profiler
The Profiler is controlled using its toolbar buttons. Here you can attach the Profiler to an existing process (or JVM), or launch the application for the active Analyzer Script. The Profiler window displays the details of the target process as it is profiled. These details provide feedback, letting you see the number of samples taken. You also have options for pausing and resuming capture, clearing captured data and generating reports. You can gain access to the reporting feature by pausing the capture - the reporting feature is disabled whilst data capture is in progress.
Weighted Call Graph
This detailed report shows the unique set of Call Stacks/behaviors as a weighted Call Graph. The weight of each branch is depicted by a hit count, which is the total hits of that branch plus all branches from this point. By following the hit trail, a user can quickly identify the areas of code that occupied the program the most during the capture period.
Stack Profiles are a taken to discover the different ways (stacks) and the count of ways that a particular function is invoked during the running of the program. Unlike other the other profiler modes, this profile is activated through the use of a Profile Point, which is a special kind of breakpoint marker. The marker is set in the source code like any other breakpoint. When the breakpoint is encountered by the program, the stack is captured. When you later produce the report, the stacks are analyzed and a weighted call graph produced. The graph shows the unique stacks that were involved in that function during the time the profiler was running, The 'Hit Count' column indicates the count of times that same stack occurred.
The Memory profile tracks allocations, ignoring when memory is freed. It uses this information to rate the executing code's demands for memory, in terms not of the amount of memory but of the frequency of demands. The Allocations figure is the total number of memory allocations requested. The Stack Holdings is the number of stack traces taken at those times, and the Heap Holding figure is the total amount of memory obtained by these calls. Note that profiling can be turned on and off on demand. There is also no need to rebuild your program to get it to work as there is no linkage involved.
This example is of a report produced from Profiling a demonstration program in the Xerces project from Apache. The program iterates over the Document Object Model (DOM) for a provided XML file.
Function Summary Report
This summary report lists the functions and only those functions executed during the sample period. Functions are listed by total invocations, with a function that presents twice in separate Call Stacks appearing before a function that appears just the once.
Function Line Report
This detailed report shows the source code for a function line by line displaying beside it the total times each was executed. We uncovered code using this report, that exposed case statements in code that never appeared to be executed.
The Profiler is supported for programs written in C, C++, Visual Basic, Java and the Microsoft .NET languages. Memory profiling is currently available for native C and C++ programs.