Initialization with NaN effects graph update

[k-waris]

Hi

Interesting finding, thought I may share it. It would be interesting to know a fix which I haven't tried!

I initialized an array with 240,000 elements using NaN. I simply used 'Replaced Array' fuction to replace individual element and built XY cluster for XY graph. It all works but!!!

Interestingly, the whole vi would slow down till each NaN element is replaced. Once all elements are replaced, the calling vi would update User Interface as normal.

If I replace NaNs with 0s in intialization phase, then there are no speed and performance issues. I do however get horizontal lines at 0 value for all channels which is the reason I wanted to use NaNs to avoid this false representation of signals.

Is this a known issue with NaNs and any fix for this?

Many thanks

K Waris

[johnsold]

This is just a guess but I suspect that the way LV reduces datasets to pixels works much more slowly with NaNs.  Your graph probably has a width of 1000-2000 pixels, or fewer. Suppose you are plotting a straight horizontal line and your graph is 1200 pixels wide. You send 240000 points which means that each pixel represents 200 data points. The LabVIEW graphs take those 200 points and perform some calculation to determine the value for the pixel.  If it finds a NaN anywhere in that group of 200 points, the pixel will not be plottted.

I suggest trying to do the data reduction yourself. Only send to the graph enough points for each pixel you want to plot. Then you get to decide how to handle the  excess points: Do you want to average them, use the maximum or minimum, plot the first or last point, or something else? By doing it this way, you only need to process data which has already been "replaced" - and you know what that is because you have some kind of index value for Replace Array Subset.  The graph never sees the NaN points because you never send any to it.

Lynn

[CoastalMaineBird]

You send 240000 points which means that each pixel represents 200 data points. 

I'm not sure that's it, Lynn. 

For a waveform graph, that's true.  you divide up the data among the number of "columns" you have to plot, and you plot the min and max of each "column".  Then you draw a line between them.

But here, where it's an X-Y plot, it seems to me that there is no reduction invoived.  You just scale the X value to a pixel column, you scale the Y value to a pixel row, and then you paint that pixel.  If it's NaN, then you don't paint it.  Do that 240,000 times and you're done.

FWIW, out of curiosity, I timed the MIN / MAX of ARRAY function.  For an array of 1024 noise points, the function takes 0.9 +/- 0.05 uSec.

When I replace one point by NaN, nothing about the timing changes.

I see no reason yet for NaNs to affect the speed that way.

[CoastalMaineBird]

k-waris, can you share your code that exhibits this behavior?

[zou]

Ran into the same problem before.  End up using a very negative number instead of NaN.

[mikeporter]

Well whether you want to call it data reduction or rescaling, unless you have a graph with an active plot area 25000 pixels wide, some sort of manipulation needs to happen. So plotting 200 values on top of one another is going to be wasteful of time.

Mike...

[altenbach · Accepted solution]

Last year, I noticed a similar slowdown with graph updates if NaNs are involved. (discussed elsewhere, not public).

Under some conditions, NaN causes slowdowns in 32bit programs. I wonder if LabVIEW 64bit show the same problem?

Also read the section "Performance implications on the x87 FPU" at this link.

[k-waris]

This is rather interesting. I have both 32 bit and 64 bit Labview installed. Just opened same projects with 64 bit Labview, replaced my 0s with NaNs and problem seems to have disappeared.

Thank you Altenbach, much appreciated.