Examples described here are based on saved TimeTrac results from
execution on a dual core Linux laptop
in SMP mode.
Results will differ somewhat from that described here based on the type
of platform used. In particular,
you are encouraged to change these examples to use a larger number of
threads and more CPUs and
observe how TimeTrac scales to much larger applications.
TimeTrac results may differ with each test run even on the same platform.
This demonstrates
the variability of the examples presented here (they are not structured
to be repeatable each time they execute).
The TimeTrac views shown here may differ from what you see on your
screen. Setting the TimeTrac display configuration defaults similar to those suggested
in the threads example (when you get there) will help minimize those differences.
Not all TimeTrac features or techniques are demonstrated with these examples;
the focus here was to provide a few examples to illustrate what
TimeTrac can do for your application development cycle.
TimeTrac is quick to learn while still providing valuable information about
your application.
In particular ...
The TimeTrac examples here require no special hardware or
software (other than TimeTrac itself) to run.
TimeTrac is a standalone utility that can be used independently of other
development environments
resulting in no disruption in the way you are currently doing things
TimeTrac requires no additional hardware or special setup to learn or use.
In these examples, the execution of a thread is displayed as an event.
It need not be this way; threads might have several (or many) events
instrumented.
For the examples here, each thread produces its own set of trace files
and has its own set of variables.
Therefore the
time_trac_open call need not set the thread_safe flag.
In your application, you may elect to collect data
from multiple threads in the same file; this requires that the thread_safe
flag be set when you make the open call.