Profiling the execution time incorrect

[GabbyG]

Hi
I am working with 6.02i under W2K on a project that does real heavy data (not neccessarily number-) crunching. The data sets are in arrays of clusters and from these I do selective paints into FP images.
So far the setup. Since the number of data sets is sometimes within the thousands I do expect considerable execution time. To optimize that, I used the profile tool of LV and also did bracket vi's to access the timer and calculate the real time between major parts of the program. Now the sum of times from the profiler is much lower than the real time elapsed. This is not due to the overhead of the profiler (I'd expect that) but can also be verified with the NT task manager.

The question where is my time spent? Any ideas are
appreciated.
Gabi

[Greg_McKaskle2]

> The question where is my time spent? Any ideas are appreciated.

It is difficult to say without looking at the VIs and results, but one
place to look is at reentrant VIs. I have never seen a profiler that
keeps recursive functions straight withouth the occasional double count,
and a highly reentrant application has similar issues.

If this doesn't seem to explain it, please consider sending it to
technical support.

Greg McKaskle

[GabbyG]

Greg
Thank you for an answer. In my case I do not use recursive functions. But I investigated a bit more. It seems more related to OS calls. Here I had for other testing purposes ticked the "Deallocate memory as soon as possible". If you do this, even a simple Sub vi to add 1+1 an return the value is grossly lengthened.
Whether it is simply the call to the memory manager or Windows uses the oppotunity to step through all other processes I cannot say.
But one conclusion is: If you really want to know how long a routine takes, measure the time between in an out and do not rely on the profiler.
Thanks
Gabi

[Greg_McKaskle2]

> Whether it is simply the call to the memory manager or Windows uses
> the oppotunity to step through all other processes I cannot say.
> But one conclusion is: If you really want to know how long a routine
> takes, measure the time between in an out and do not rely on the
> profiler.

I think that explains it. If the times of the profiler are less than
the wall clock time, then it sounds like the profiler is measuring the
execution time, but not necessarily including the teardown of the memory
deallocation.

I'd definitely encourage you to leave the deallocation setting turned
off as it leads to lots of time spent in the memory manager and
eventually to fragmentation of the OSes memory manager. It is much
better to spend some time avo
iding buffer copies as mentionted in the
performance chapter and other devzone articles.

Greg McKaskle