"Not Responding" UI (Win10) LV 2019.01f1 or 2020 - with "large" data sets - same VIs worked fine in older LV versions

[BobENose]

Hi folks - longtime LV user, finally updating an OLD OLD LV program (likely last built using 2017, windows 7) to Windows 10 either LV 2019 or 2020 (tried both so far)

The program grabs 4 sets of data ~2,000,000 samples each, manipulates these down to a data set of about 4x125,000 and passes this around to be worked on.

This program USED to work, no issue, in older LV versions - however after installing and loading the (unmodified) code, the LV interface is basically unusable after the  VIs have been run (as in - I RUN the VI, it captures its data, processes it (notably slower than older versions), and upon COMPLETION, the VI finishes, with no error.   To be clear (er), LV works fine when the VIs are first loaded, the UI experience would be as I expect,  but after capturing the data and running the analysis (so all the different VIs now have the data set (or pieces of it) loaded /acted on)  the UI is virtually useless.  Windows become "not responding" just by clicking on them (when NO VI IS RUNNING),  and the front panels cannot be manipulated -- clicking on an item, or right clicking, results in the same "not responding" behavior, with the usual Windows 'ghosting/greying' of the window that is not responding.

Details -

  1) Windows 10 1909, 64-bit,  and yes,  I've always used the 64bit version of LV, both years ago, and now (2019 and 2020) - I am trying (as I type this) a 32-bit version of 2019.01f1 to see if that actually behaves differently. 

  2) Windows itself never bogs down, has plenty of memory, and never 'maxes out' much past 4 GB of RAM used (16G is available to it)  Update:  Yup,  just over 4G used, so the 32bit app blows up, with an 'out of memory' issue - so 64-bit remains my only version of interest.

 So - as I haven't been paying attention to Labviews 'advancements' in the past few years,  what have I missed that would so dearly compromise UI behavior, and overall performance with "large" data sets?  (and no, I don't really consider 4 x 2million samples "large", but that's another story)

For a bit more, my use case generally needs 5-6 VI front panels open,  with various arrays shown of the data set,  and a handful (1-2) waveform graphs -- nothing I would consider excessive (especially given this all worked fine in older versions.

Thoughts and suggestions appreciated.

[MichaelBalzer]

Do any of your graph plots have anti-aliasing enabled? I find this is a massive performance hit whether running or not.

I also hit edit time performance issues with graphs, causing the CPU to max out in this thread. The fix was a labview.ini setting to disable live selection updates:

LiveSelection=False

[BobENose]

LV 2021 Update (same bad behavior) 

Thanks for the pointer MichaelBalzer - unfortunately I never used Anti-Aliasing.  What I know is a huge factor is my need to not use connected lines in my plots, instead drawing discrete objects.   I also recognize that LV is decimating my data (~500,000 samples, 4 data plots on the same graph, so ~2Million points).

My HUGE annoyance at NI / Labview is  this worked perfectly fine in older LV (2017 & earlier) -- and I have just confirmed that this is still seriously bad (even worse actually) in LV 2021 ---  after my program runs and my plots fill up, the UI flashes (different windows randomly select/flash/come-to-foreground) and overall the LV environment is "not responding", up until when I minimize the VI with the offending plots.   When I un-minimize that window,  it is then entirely black (the entire VI panel, other than window border and title bar and menu) 

  This is a real shame,  as Labview USED to be to the go-to choice for quick plotting and UI construction wrapped around some reasonable signal processing/analysis   -- but if it has regressed so badly that you have to carefully manage the data environment of the plots yourself, I might as well go back to my Java/JavaFX and Mathworks/Matlab world.

  As I've typed this, I have been running my program with LiveSelection=False in my INI,  and I also went through and disabled all but one Waveform Graph output, and made sure Smooth Updates was also disabled - I have 3 LV windows open (project, main, and the VI with the graphs) and LV keeps periodically flashing the main window, bringing the project window to the foreground, then back to main, all while the "VI with the graphs" is running (with no active graphing updates) -- its really sad to see such regression.   Upon code completion, the VI continues to flash, generally the "x" close box will flash red and/or "not responding", and the UI is still basically useless while the "VI with the graphs" is not minimized -- as SOON as I minimize, LV returns to "normal" and is useable  (but there's sorta a reason why one plots graphs, so making it impossible to USE the graphs really makes me look at other non-NI options -- though I would love a 'quick fix' -

   and yes, the 'quick fix' is to turn the Waveform Graph back to its default line-plot, rather than "x' (or . or square, etc) plot per point  (it was a 'common plot' with squares as shown below,  but simply moving to the line solved all this UI/performance problem --- but unfortunately in my use case, that makes the plot useless,  I cannot have connecting lines to visualize the data I am looking at - so unless "modern" LV has a better Waveform graph that can plot unconnected points better,  I'm back at looking enviously at some other non-LV tools

   Machine is Windows 10, latest updates, 32GB ram, quad core, CPU never above 43% utilization, RAM never above 16GB

[MichaelBalzer]

Hi BobENose,

I just tried 125k point plots on 4x waveform graphs, and toggling between the the line plot style and the discrete point style, and am seeing exactly what you're describing. This is using LabVIEW 2020. I found if I change the point style from the open square to a closed square, there's a small speed increase, but is still nowhere close to the original connected line plot style.

Even after stopping the VI the LabVIEW interface is laggy, up until the data from the graphs is cleared. I've not tested under LabVIEW 2017, but it sounds like a regression. I believe this is around the time graphs and other controls were being tweaked to include NXG style support, so maybe an issue was introduced then.

Is plotting fewer points per graph an option? Or perhaps viewing a subset of points on the graph, with a slider to control the axis limits.

I share your annoyance though. NI's being playing with editor enhancements the last few versions of LabVIEW (maintain connected wires, transparent selection rectangle, and 2021's auto wire routing bug), which add very little, but have seen large performance and productivity slow downs.

[BobENose]

Hi Michael,  thanks for confirming.    I fully understand that treating the connected line as discrete objects will greatly slow performance,  as I certainly see such in other languages as well,   the full annoyance is simply that exact same code, upgraded from earlier versions,  goes from "useful" (and honestly, not that slow),  to not just unusable, but crippling (having to kill labview at times, or otherwise close out fully just as a result of loading and plotting data)

Since my use-case can't use a connected, I built my own crude custom "filter/decimator" (since there are points I have to see, and points that can be thrown out) and that works well enough,  and (obviously) when going from 500,000 points per plot to ~500 the performance is grand.   

I appreciate that version upgrades might introduce breaking changes,  but I can find NO listing of such a change even being hinted at, and as I continue to fight through other code issues with my 'old' code upgraded to LV 2021,  I have to wonder how many of these issues are because of other changes.