This section provides help with Quantify messages, data collection, and data analysis.
If you get this message, you need to add at least 13 megabytes of swap space to your configuration. You can increase the swap space on your machine or instrument your application on a machine that has more swap space.
The first time you link with Quantify, you need more swap space than on subsequent links, because Quantify instruments and caches versions of all the libraries your application uses.
To determine the current swap size and increase it, use the appropriate commands for your operating system. See the manual pages for each command's options and arguments.
To determine the current swap size, use the swap -s command.
To increase your swap space, use the mkfile and swap -a commands.
To determine the current swap size, use the swapinfo command. To increase your swap space or increase the data-segment size limit, use the sam (System Administration Manager) application. You must be root to use these commands.
ld: /usr/local/quantify/cache/lib/libc_pure_q512_200.sa.1.7:
warning: table of contents for archive is out of date;
rerun ranlib(1)
Your workstation's clock is out of sync with your file server. To synchronize them, use the command:
root% rdate file-server
You must be root to do this.
Quantify and /bin/time measure time in your code and time in system calls differently.
The system utility /bin/time reports times measured by the kernel for your process. When the kernel switches to and from user state for your process, it adds the elapsed (wall-clock) time to the user time measurement for your process. In kernel state, when the kernel switches to and from another process, it adds the elapsed time it spent on your process to the sys time measurement for your process. When the kernel waits for a device, this elapsed time is not added to your sys time measurement. These measurements include time spent handling cache misses and memory paging but exclude time the kernel (and your process) waited for response from a device or another process.
In contrast, Quantify counts instructions using a technique that excludes cache miss and paging effects. By default, Quantify also measures elapsed time for operating-system calls which, from your process's point of view, includes any time required for the kernel to wait on devices or for other processes to run.
Quantify underestimates the time /bin/time reports in user code, since it does not measure memory effects, and predicts longer system times than /bin/time because its measurements include wait times that /bin/time excludes, but that represent a true cost to your program.
You can tell Quantify to measure system-call time using the same technique as /bin/time by using the option -measure-timed-calls. See also Timing system calls.
Because Quantify measures the elapsed time required by the operating system to perform an operation such as a call to write, the measured time varies from one run to another. In particular, the measured time depends on the status of other processes as well (your process might be swapped out) and the cost to perform the operation on a particular device. Since Quantify counts instructions, the Time in your code will be identical between runs.
Quantify measures system-call times by calling either the gettimeofday or the getrusage functions. If the operating system performs a context switch during one of these additional function calls, the measured time of the operating-system call will appear longer than it actually was. Quantify cannot adjust for this effect because it cannot detect that it has occurred.
This typically happens because your program is making a very large number of very fast system calls in a short period of time, for example, calling the function gettimeofday in a loop. This effect is negligible in normal programs. You should consider avoiding recording system-call times during these periods. You can also avoid recording the specific system calls with high-call counts that occur during this period.
For more information, read How Quantify times system calls.
When Quantify finds a static-function definition without a corresponding name in an object module, it names the function unknown_static_function. It then appends the object filename and function offset to distinguish the function from any other unknown static functions in the same or other object modules. See How Quantify names functions.
In shared libraries, the linker creates stub functions for various purposes but does not give these functions names. Quantify, however, requires names, so it gives these functions names such as uwss_NNNN. These names do not appear in gprof.
Different compilers build their debugging information in different ways. Some C++ compilers tend to put incorrect line numbers in the debugging information in the code. Quantify uses whatever debugging information is provided to indicate line numbers. You can sometimes see similar behavior in debuggers.