Optional DVR input to controls

[LV_Tim]

I would like the option to connect a control/indicator, such as a Graph, Table and Arrays, to a matching typed DVR reference. 
This would allow the developers to work on large datasets in-place and the connected indicator would reflect that change with out having to pass, essentially, a large copy of the data to the control/indicator. 

The speed and memory efficiency improvements could be huge for large datasets.

[LV_Tim]

I should’ve noted, this only required for controls and indicators that are being used as UI elements.

[fefepeto_kb]

If I understand the idea correctly, then you propose to use the same memory space for the controls and indicators to be displayed, where the actual data is stored. While it might seem to be a performance improvement, it would likely have a negative impact on the application. Here are a few reasons, why the data in the memory for the UI is buffered:

• UI needs less updates therefore it updates less than the actual data in the memory.
• The UI drawing process takes place for the updated portion of the UI. If there are more then one elements changing, then all the elements will be updated before the next data readout can happen.
• If the UI elements would use DVRs then the data could not be updated while the UI (re-)draws the element causing potential dropouts or data losses. Any data integrity problem would be bad for the application's processing capabilities.
• A generic monitor is updating ~60 times per second (expressed in Hz when talking in terms of vertical synchronization, or fps when talking about displayed information), therefore quicker updates would not make sense anyway.

Here are some recommendations for displaying large datasets efficiently:

• Limit the actual displayed data to a useful amount, the user potentially cannot comprehend thousands of data points if their screen resolution is Full HD or 4K.
• Create combined controls that allow browsing the large datasets by accessing smaller chunks of the data based on user input. Practically this would be a selective display.
• Where applicable display a processed summary of the data, like histograms, standard deviation, statistics.

To be honest, I see more drawbacks of the idea than advantages, which would result in performance degradation. I would prefer to keep the UI elements buffered, as in other languages as well.

[Intaris]

This sounds like a cool idea on first reading, but the access control and possible race conditions not to mention locking mechanisms required to make this work would quickly make such an approach quite unreasonable.

It would end up coupling all DVR actions of the UI element to the UI thread (due to access control neccessity when redrawing), something which might work fine in a small test VI, but causes enormous headaches in and middle-to large application.

The speed benefits you envisage would disappear rapidly in any real-world application. fefepeto_kb hits most of the points II would have otherwise additionally added. I'm not saying data handling for UI elements cannot or should not be improved, but this, in my opinion, is not the way.

[GregR]

In most cases the contention on the DVR would invalidate any performance benefit from removing the copy. Controls don't just access their data when they are told a new value is available. Arrays or tables need their data when they are scrolled. Graphs need their data when the scales are changed. Many controls need the data to show menus or handle clicks. Many of these operations would hold the data for 10s or 100s of milliseconds. That may not seem like much but when the diagram is blocked during that time, it would have significant impact on code performance.

Behind the scenes LV is already doing something like a DVR to manage the data. It isn't literally a DVR, but we have a lock that controls access to the one copy of the data used for execution. To minimize the duration of time that this lock is claimed by the UI, making a copy inside the lock is commonly the fasted thing to do.

[Christina_R]

See comments for explanation of why this change wouldn't result in performance improvements.