LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Replace Array Subset w/Shift Register too Slow for my Application

Solved!
Go to solution

This is similar to other posts, but I haven't found one that addresses the limitations of a shift register approach.

 

I have a part of an application that I am trying to run at 500-1,000Hz.  The process gets a chunk of data from an ADC and I need to store this data and then collect more from the ADC.

 

I've put together what seems to be the bottleneck of this in the attached .zip file.  When I run the attached code with profiling (see .PNG file), it is telling me that on average it takes 3.8ms for the SubVI to run.  At that rate, I can only run around 260 Hz.  I have a SubVI similar to this in my code and the code can execute at 1,000Hz without this subVI, but slows to around 160 Hz when it is enabled.

 

Is there some way I can collect data arrays of around 1.7kB and run at the speeds I need?  Any input would be appreciated.

Download All
0 Kudos
Message 1 of 9
(4,619 Views)

You can try replacing Raplace Array Subset by the In Place Element Structure with Index Array/Replace Array Elements option, this should increase performance.

 

Won't work, can't use a disable page index.

 

Ben64

0 Kudos
Message 2 of 9
(4,603 Views)

I have been running this some more and now I am getting 12us average time, which would be plenty fast....not sure why...

 

Yesterday, on another machine running my ADC code, this was around 4.2ms.

0 Kudos
Message 3 of 9
(4,579 Views)
Solution
Accepted by topic author thad_tensentric

For benchmarking purposes. Debugging should be disabled on the sub-vi.

 

Looking at the code you provided - don't just disable debugging- ! you have a few other "Execution" options to reset.

Capture.PNG

 

That ought to speed up the sub-vi a bitSmiley Wink The SR will become your friend again!


"Should be" isn't "Is" -Jay
0 Kudos
Message 4 of 9
(4,557 Views)

 

I don't know why it is, but I almost *never* glean info out of the profiler that I consider both useful and trustworthy.  I regularly see it telling me things that are either untrue or else technically true but unhelpful.  

 

I've speculated before that maybe the timers start when a subvi becomes *eligible* to run based on dataflow rather than only timing actual execution.  That idea's probably not true, but it did a much better job of explaining the timing measurements the profiler showed.   It's not just about the absolute times, but the relative ranking of times where I regularly see inexplicable results.

 

Sorry, no demo or example here, just kinda venting.  But I'm curious, is it just me?  Do others find the profiler to be a largely effective tool?  What might I be doing or interpreting wrong?

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 5 of 9
(4,531 Views)

Thanks Jeff Bohrer for this. I've tried changing these settings in my VI and the results are the same...for some reason though, earlier today I got the 3.8ms from the profiler and now it is always 12us.  Maybe this is Kevin's point...

0 Kudos
Message 6 of 9
(4,524 Views)

I don't understand the reason to even create this subVI, because it just duplicates the "replace" primitive. Don't just repackage existing functionality! Nothing gained except potential confusion. Is there more to it?

 

If you benchmark the code, you need to make sure that the frontpanel of the subVI is not in memory (e.g. if you have it open, etc.), because it will update all its controls and indicators, which is relatively expensive for such big data structures. Inline the VI as suggested by others or at least make sure that the subVI front panel is not in memory.

 

I haven't studied your code, but you want to make sure that things are arranged in a way that the replaced 1D array sections are contiguous in memory order. It is cheaper to replace a contiguous stretch than to replace one element at a time spaced distances apart (e.g. in a 2D array, it is better to replace rows instead of columns because of that reason).

 

0 Kudos
Message 7 of 9
(4,519 Views)

I think the solution is a combination of VI execution settings.  I've seen different behavior when changing these settings and I'm not exactly sure what did it.  I currently have too many other things to do than to hunt this down.

0 Kudos
Message 8 of 9
(4,456 Views)

@thad_tensentric wrote:

I think the solution is a combination of VI execution settings.  I've seen different behavior when changing these settings and I'm not exactly sure what did it.  I currently have too many other things to do than to hunt this down.


When you do get a bit of breathing room, just hit that "Help" button on the Execution Options page shown in my previous post.  Most of what you "don't have the time to track down now" becomes clearer with reading that page and the internal help file links.  Some "Googling" may be required.

 

Glad I could be of assitance!

 


"Should be" isn't "Is" -Jay
0 Kudos
Message 9 of 9
(4,367 Views)