Slow plot update with array initialized with NaN

[PolymerTim]

I'm working on a data acquisition program and am trying to implement some of the suggestions I've seen on this forum for handling large arrays and displaying them.  I think I'll have more questions on this later, but I've run into a surprising effect and wanted to see if you guys could help explain it. 

My plan is to keep my data array in the shift register.  I will initialize and use replace array subset to reduce memory reallocations.  Since I am plotting the array directly, I don't want the initialized data showing up on the plot, so I am initializing the arrays with NaN.  My observation is that it takes much longer for a labview plot to update when writing NaN than with a real number of the same representation.

Interestingly, the loop processing the data and sending it to the plot is not slowed down by this effect, but the plot itself updates much more slowly than the loop does.  I'm including an example program to illustrate the effect.  With it, you initialize an array and the loop continually sends the array to the plot with or without decimation (by a factor of 100).  Indicators show the ms/loop iteration and the current iteration count.

As expected, making the initialized array larger slows down the loop and decimation speeds up the loop, but I didn't expect the intialized value to have such an effect.  A couple of scenarios to illustrate the point:

1) Set array size to 1,000,000 points and initialize with zero and no decimation.  Notice the ms/iteration and how quickly the iteration count seems to update.

2) Now change the initializing element to NaN, and re-initialize.  Notice how the ms/iteration is the same, but the iteration counter is clearly updating much more slowly. In both cases, I note that the memory assigned to labview is about the same (although large).

I realize the more elegant solution would be to reduce the size of the array before plotting (something I'm working on), but I am still curious about this effect.  It is hard to quantify since labview seems smart enough to keep the loop going even if the front panel is struggling to update, but the effect can be clearly seen.

What do you guys think?  Any explanations?

[JÞB]

Actually I see 1 %20 improvement in loop speed with NaN  (Makes sense there are a lot fewer pixels to render for the draw)

Let's see what VI Analizer shows....

Whoops dead code here.  Watch those apparently wired tunnels!

But nothing to indicate any major issues with the FP like overlapping objects.  (when objects overlap BOTH need to be redrawn when either are redrawn)

One other high priority result:  Wait in while loop: This While Loop containing a front panel control terminal appears to have no way to regulate its speed.  If this is a subVI, consider moving the control terminal outside the loop.  If this is a user interface VI, consider using an Event Structure to monitor front panel activity.

That means we are really overloading the UI thread  but we actually DONOT want to slow the while loop.  Hmmm...

Time to bust out the template design patterns.  The User cant really see updatdes faster that once every 50mSec

So we can try to move to a Master- Slave pattern

Running this we get a 2x boost in the top loop speed but add a data copy (or two) of a rather largeish chunk of data 100x/Second so we service a lot of memeory movement.  better but not quite what we want.  Super ideal for smaller arrays though: jot that in your notebook - Try the code with smaller arrays like 100K and loop speed goes into the dirt.  so now it really is memeory operations that are throttling the UI.  managable.

[JÞB]

You might squeeze a bit more out of it using a DVR but I figure improving your loop speed by too much more than the few thousand times I did in 10 minutes might just make you angry

[altenbach]

Yes, well, an xy graph with 1M points will tax the UI thread no matter what.  It is curious that the update is slower with NaN, but this is probably dues to the extra processing of the exception handling. I agree that it should take faster to plot NaNs, but NI decided to optimize for plotting of actual data. I think this could be improved internally.

To benchmark the actual graph update time and monitor it via the loop rate, you should change the graph to synchronous display (right-click...advanced. Of course not recommended for regular work!!)

I get about 110ms if x and y are both NOT NaN, 430ms if only x OR y are NaN and 750ms if both are all NaN. Since it is sufficient if only x or y is NaN for the point not to show, you should only change one of them.

I guess that this code would really suck on a single precessor system, where the UI thread needs to be handled with the same CPU core.

Do you really need an xy graph? Are the points really not spaced equally in X? And yes, it is of course silly to try to show 1M points on an xy graph that is only a few hundred pixels wide.

[JÞB]

Just to prove I could go there:

While having a smoke I realized a few things.

The xvi is SLOW:

I needed a more precise timer (luckilly there is one)

No need to duplicate the WHOLE data cluster

the IPES isn't really needed with the 2013 optomizer

Loop time is <2uSec at 25M (there is only finite memory)
25m/2u >12,500X speed at 25X data size

Don't be angry

Edit CA the NaN did graph %20 faster at 1M points

[PolymerTim]

Jeff,

Thanks for the input.  I probably should have been more clear that the attached vi was not my working program, but simply an illustration of the effect I saw while working on my main program.  I intentionally burdened the UI to see the effect of the initializing element.  My working program of course uses a producer/consumer design with a 50ms update rate for all front panel objects.  In that case I was playing around with how large an initialized array I could use without causing problems when I noticed that with large arrays, the plot refresh rate slowed dramatically.

Altenbach, Thank you for the "synchronous display" detail.  I was not aware of that option, although it sounds vaguely familiar now that you mention it.  Your numbers are consistent with my visual observation in that having NaN for both x and y is even slower.

As for my actual program (again, I plan on starting another thread with questions on it another day), I could limit the user to a constant sampling rate, but I think it would be a nice feature if the user could adjust the sampling rate during the experiment.  For instance, our signals change much more rapidly at the beginning of the experiment and then slow down, so it would make sense to change sampling rates to accommodate.  My plan is to keep the hardware sampling rate constant, but average different sized blocks of the incoming data to alter the recorded sampling rate. This is why I went with the XY plot.  I guess I could string waveforms together on the same plot, but I will have 8 signals (each color coded) with a plot legend, so I imagine that could get messy fast.  I think I can get the performance I need from an XY plot and keep the coding much simpler.

[JÞB]

Re reading.

Altenbach and OP Source code ran at 25mSec/iteration with 0s and 20mSec/iteration with NaN as I saw it.  running Win 7x64 OS on a DELL Laptop with an intel core duo @2.48GHz (I'm not bragging just saying)  x32 LabVIEW 2013.0f2

[PolymerTim]

Jeff,

Just to clarify, when you say the NaN ran faster, are you looking at the loop timer, or the front panel refresh rate?  It is the front panel refresh rate that I notice getting slower when NaN is in the array.  If you don't see that, it makes me wonder if there is some system dependence.

[JÞB]

---

@PolymerTim wrote:

Jeff,

Just to clarify, when you say the NaN ran faster, are you looking at the loop timer, or the front panel refresh rate?  It is the front panel refresh rate that I notice getting slower when NaN is in the array.  If you don't see that, it makes me wonder if there is some system dependence.

---

Yes,  THAT I saw!  and the poor UI response was the main reason I went out for a smoke after my first post.  I really had not fixed that yet.  The second example decimating the array prior to notification showed no refresh lag (up to memory fault).  Thanks for clearing that up.