Thanks, I will add this link to App Profiler page.
If you using IDE it will set all these env vars automatically.
QPROF_ON - it is on by default if you set it to 0 it will be off
QPROF_KERNEL_TRACE=1 - profiling will generate kernel trace events instead
of creating data dump.
If you using kernel logging from IDE at the same time (you can enable it
from launch configuration)
it will record all these events in .kev file (used by System Profiler). You
can open this file in system profiler and see function enter/exit events,
and you can import it in App Profiler same as trace file.

About text file - you are right it is just ASCII for now, but it is work in
progress, we are looking at some ways to minimize it now, including using
target side aggregation, also some approaches like archiving it can give
much size reduction then using binary format...

When using Sampling without any instrumentation overhead is neglectable.

When using Call Count instrumentation it is bigger. When profiling is 
"stopped" it still collects data but does not send over the wire (but 
collected data includes only count of functions calls, not timestamps).

When using Function Instrumentation every function has overhead on enter 
and on exit, additionally when buffer is full the longest operation is 
to dump butter to a file. This time (overhead) however is extracted from 
final results. For multithreaded environment function instrumentation 
won't work very well because it does not measure thread time, it measure 
total time. So if two functions are run in parallel (pseudo parallel on 
one processor) and finish at the same time, deep time would show them 
taking same amount of physical time, even they took 2 times shorter. So 
if you application has concurring threads you should ether use sampling 
or system wide profiling.

Richard Virlouvet wrote:
>
> Dear Elena,
>
> I can see in the IDE4.5ApplicationProfilerTrial Wiki page, about 
> application profiling, the following sentence: "It better works for 
> one thread, because with many threads overhead of such measurement can 
> change application behavior.".
>
> Is it the same for instrumented system profiling ?
>
> The overhead exist:
> - at any time ?
> - only when Tau is connected to the running process ?
> - or only when profiling ? (it means Tau is connected to the running 
> process, but the new "start/stop" profiler feature is off)
>
> Thanks.
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post7033
>