Using the Standard Calls Report to isolate a function hot spot may not be sufficient if the function consists of thousands of lines or many loops. To help in this case, the Source Lines Report lists the individual source lines that are taking up the most time, providing the user with another method of trying to locate performance bottlenecks. In addition, the user can select a range of code for timing analysis.

Sometimes a programmer can't figure out why an isolated source line is taking a lot of time. Clicking on the assembly icon button interlaces source code with machine instructions and displays the profiling information on an instruction by instruction basis. Looking at the details of the assembly code can sometimes be revealing; for example, a lot of time can be lost due to effects such as consistent cache misses, which may be clustered around specific assembly instructions.

Profiling Methodology

MULTI employs various schemes for collecting profiing data, depending on the capabilities of the target system. When developing programs for a system running UNIX, MULTI uses compile time options to make use of the profiling data collection capabilities provided by the operating system. When used with a simulator, MULTI uses the simulator's model of the target processor to determine processor timings. Embedded programs using ROM monitors typically use a regular interrupt to sample and store the location of the program counter. In-Circuit Emulators usually have a mechanism whereby trace information can be interpreted as profiling data; depending on the emulator, this can be done either automatically or manually.