LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why is are the timing statistics wrong in Performand and Memory Profiler?

Solved!
Go to solution

Hi,

 

I have a subvi which I have timed with a stopwatch at 88 seconds, and the profiler is telling me that the total time is 20 seconds.  The subvi is activated with a button, contains a for loop, and is the last action in the program.  Everything still scales as expected - if I decrease the number of iterations inside the subvi's for loop by a factor of 10, I can then measure 9 seconds with my stopwatch, and the profiler tells me 2 seconds.  What is going on?  Why is the profiler so far off?

 

Ken

0 Kudos
Message 1 of 8
(2,923 Views)

Ken,

 

without seeing the code of the subvi, we can only guess.....

My guess is that you have waiting functions in the vi. This will therefore explain the difference since wati functions do "pause" the execution of the VI and do not count towards the time taken in the VI......

 

hope this helps,

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 2 of 8
(2,920 Views)

Norbert,

 

Thanks for the reply.  I've posted a picture of the subvi.  It's relatively simple with no explicit wait functions.  Any additional input would be helpful.

 

Ken

 

subvi.PNG

0 Kudos
Message 3 of 8
(2,906 Views)
Solution
Accepted by topic author halvorka

Ken,

 

the AVI Read has an implicit delay included caused by the framerate of the video you are reading. If the fps (frames per second) of the video is e.g. 30, you will have to wait between two frames 1/30 s =  33.3 ms. During this waiting time, the Profiler does not show the calling VI as active. The tracked time taken in the caller does only contain the loop and the call to IMAQ AVI Read Frame.vi. Not the time this subvi takes.

If you look into the time taken by IMAQ AVI Read Frame, you won't see the "waiting time" as well, since it is again only a function called by this VI.....

 

hope this helps,

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 4 of 8
(2,897 Views)

Brilliant!  Thank you - I would have had a tough time figuring that out.  That is for sure what the problem is. That seems like a strange "feature" of the AVI Read Frame.vi though.  So if I want to process an AVI video as fast as possible, is the only way to change the framerate of the AVI?  What about the frame read "lookahead" parameter - could that do it?

 

Ken

0 Kudos
Message 5 of 8
(2,888 Views)

halvorka wrote:

[...]That seems like a strange "feature" of the AVI Read Frame.vi though.  [...]


No, it's plain simple. If you have e.g. a VI with an event structure in it repsonding to UI interaction, the time it takes until the user fires an event will not show up in profiler. Why should it? The process controlling the VI's execution is sleeping until the user interacts with the UI. That's the reason why event based programming is most often superior to traditional polling.

 

Regarding the Frame Read Lookahead, there is obviously no documentation installed with LV. Luckily, the online help contains the information:

Documentation

 

 Reading this it seems to me that it does not change the behavior of playing videos using IMAQ. So the only way to reduce playing time would be a conversion of the video which increases the framerate per second.

 

hope this helps,

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 6 of 8
(2,880 Views)

Norbert,

 

I wasn't implying that waiting for an event should show up in the timing statistics.  Instead, I was saying that it's strange that the AVI Read Frame has a built in and undocumented wait based on the frame rate of the AVI.  This makes it difficult to process an AVI at any rate except the native frame rate - In my case I'm taking long movies and I want to analyze them afterwards as fast as computationally possible.  As far as I can tell I will have to convert frame rate of the video outside of labview first and then process it in labview to achieve this goal.

 

You've been very helpful. Thanks.

 

Ken

0 Kudos
Message 7 of 8
(2,870 Views)

Update: I think the timing problem was actually due to the profiler not counting hard drive read time.  When I changed the frame rate of the avi from 15fps to 60fps, I got exactly the same timing statistics.  My avi read performance seems to be limited by my hard drive speed (Running the same program on a faster hard drive increased my speed).  Perhaps the AVI Read Frame.vi is considered to be finished executing when the hard drive starts transfering the data, as opposed to when it is finished?

 

0 Kudos
Message 8 of 8
(2,826 Views)