05-04-2016 09:12 AM
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.
Solved! Go to Solution.
05-04-2016 09:32 AM - edited 05-04-2016 09:36 AM
05-04-2016 10:24 AM
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.
05-04-2016 11:40 AM
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.
That ought to speed up the sub-vi a bit The SR will become your friend again!
05-04-2016 01:04 PM
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
05-04-2016 01:10 PM - edited 05-04-2016 01:12 PM
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...
05-04-2016 01:12 PM - edited 05-04-2016 01:23 PM
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).
05-06-2016 08:08 AM
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.
05-07-2016 10:58 AM
@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!