04-12-2010 08:19 AM
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
Solved! Go to Solution.
04-12-2010 08:23 AM
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
04-12-2010 08:44 AM
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
04-12-2010 08:55 AM
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
04-12-2010 09:07 AM
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
04-12-2010 09:17 AM
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:
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
04-12-2010 09:41 AM
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
04-13-2010 01:22 PM
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?