Unexpected array processing performance

[Quintin]

Hey everyone,

I've been trying to process some integer array data (grayscale image data) and squeeze out every bit of execution time I can and ran into an unexpected situation that I was hoping someone could shed some light on:

I started removing subVIs I had in my process and expected to see my loop time decrease, however in removing one of my VIs and replacing it with what I assumed was a simplier/faster To U8 function, my loop time slightly increased (~32ms -> ~35ms).  Initially I thought okay maybe there is added memory management to convert an array of I16s to U8s instead of converting element by element, but if I were to replace my I16 array constant & To U8 function with an already converted array of U8s constant the speed degradation still remains.  Any idea why this would be the case?  Attached is a screenshot as well as the code (LV2012).

Thanks in advance,

Quintin

[Quintin]

My apologies, I think I found the issue in my test code, the array being passed to the U8 function contained more bright pixels that the subVI was filtering out, therefore increasing the number of pixels to analyze.

I think I still may be experiencing some unexpected issues with the execution time increasing after stripping functionality out, I will further investigate and post additional details.

[Quintin]

Ok, so I am experiencing something strange still and I'm wondering if anyone else is able to reproduce it. 

1. Close down LabVIEW completely
2. Open & Run the BENCHMARK_Full.vi in the attached zip file - I get around 18 fps when it completes
3. Then all subsequent runs after the initial run, I get around 7fps.

Closing down LabVIEW complete and reopening, the first execution I get back up around 18fps again, but after that back down to 7fps.

I experienced this on a Win7 64bit embedded machine with an i5.  Running it on my Win7 64b Pro i7, I do not see this behavior and consistently get around 25fps.

Perhaps something strange wtih Win7 embedded?

thanks,

Quintin

[Alex-D]

The decrease in run time is expected behavior for a VI. This is due to the VI being loaded into memory on its first run and then each run after that uses the preloaded data. LabVIEW only unloads the VI when you close it. As for the Windows Embedded 7 the performance you are seeing might be related to the SuperFetch technology as it loads commonly used applications and libraries into memory before you need to use them to increase the performance of your applications. That is probably why you don't see a performance gain after the first run. 

[Quintin]

Hey Alex,

Thanks for your reply, I should clarify:  I am experiencing an INCREASE in run time on subsequent runs of the VI, aka a DECREASE in performance.

Some additional info on the issue after some more testing this morning:  the Find Centroid subVI which is last in line to execute is known to be the main execution time hog in the loop.  I had originally used a queue internally in that VI to queue values that need to be processed/acculumated inside the same VI.  I removed the queue and just used a shift register and the issue appeared to go away.

[Alex-D]

Sorry about the misunderstanding I thought I read ms not fps. I ran your posted code on my machine and saw a marginal increase in fps after the initial run. First run was 20.2 fps and the following runs resulted in a 21.2 fps. Also did you mean at the end of your last post that your question was solved/problem went away or just that a problem with the Queues went away. If you are still having problems post the new code and I'll take a look. There is no reason that I can think of that the fps should drop when you run the vi after the first time. The fps should increase (not much but still increase). 

[Quintin]

Hey Alex,

Yea I don't seem able to reproduce the issue on my machine that is Win7 x64 Pro, i7 processor, only on the Win7 embedded machine where of course the code needs to ulimately be deployed to.

The issue seemed to go away when I removed the queues and used shift registers instead.  So for now the issue is resolved, but would like to know why queues cause this issue on the Win7 embedded machine.

thanks,

Quintin

[Alex-D]

Were you closing your Queue references when the vi finished? If not you may have had a memory leak which wouldn't be noticeable on your Windows 7 machine but may be very noticeable on the smaller embedded system. I am glad that using the shift registers solved the problem. Have a good day.