ProbeVue While still young, and lacking a depth of providers / probe points, ProbeVue offers distinctly unique capabilities from other tools. ProbeVue uses multiple providers for probes. For example, ProbeVue can use trace hooks as probe points, and it relies upon /proc for some capabilities.

trace The trace binary name is a bit misleading as there are multiple ÒwrapperÓ utilities that capture a set number of hooks, and then parse/format the results. The key difference between trace and any of these other tools (after system load) is the complexity of rolling your own utility using this tool. Even finding the right hooks can be challenging for most admins, let alone retrieving the data from a trace file, parsing the binary data, and then displaying it. The PerfStat API looks absolutely simple by comparison.

truss and all proc based tools are focused on looking at the interface between the application and the system. The interface being system calls, faults, and signals. (truss can view library calls, but tends to be used for the system interface.) The phrase ÒapplicationÓ here referring to a specific application being watched.

topas is really a reference to all LibPerfStat based tools. I chose topas as the header for this column because so many of the LibPerfStat APIs are clearly working under the covers. ProbeVue does not have a LibPerfStat provider at this time, and there does not appear to be a linkage on the roadmap Ð although I think there should be.

Profiler is really a generic reference to any profiler packaged with a development environment (possibly excluding Java tools). The key point is that profilers tend to be geared to a specific binary type and do not come with the system. So for an administrator to profile an application on a production system, at least some of the development tools must be installed in the production environment, the application may require a special debug build, and it is likely that the application will need to be launched from the profiler process.