Optimizing update by reference - minimizing context switching?

[tbd]

Greetings,

      We're displaying thousands of signals (collected from ~ 20 RTs) in a Table control.  Some of the signals are boolean and indicate fault-conditions - for these cell-values we want to change the BG color to green or red - depending on cell value.

A simple VI with a Table of 1000 rows (1 column), will update cell BG color [by reference] at about 550 cells/sec (with DeferPanUpdts = True.).

The same update, performed in the "bowels" of or main application, runs at about 15 cells/sec - unacceptably slow.

According to the task-manager, we're running between 20% and 30% CPU#0 (less on 1, 2 and 3) , without doing the color-updates, and CPU usage doesn't change noticably with color-updates.

There's "a lot" going on in our UI.  By "a lot" I mean we're driving 4 large LCDs, each with a dedicated reentrant GUI VI, and each GUI may have multiple sub-panels.  We've already observed some odd conflict between chart-updates and event-handling, when chart-update had to complete before events could be handled.

- Has anyone else observed and characterized this "curious" slowness when updating FP control properties by reference?

- I've read here that referencing an FP control property causes a context-switch to the UI thread, and wonder if context-switching may be to blame(?)

- Could there be an advantage to running the subVI in the UI thread?

- What do other programmers do to minimize context-switching?

Any ideas are appreciated,

Thanks/Cheers!

[tst]

You could find out if context switching is to blame by setting the subVI to run in the UI thread. If it's faster, then the answer is yes. This will also answer your question to whether there's an advantage to doing this. You should note that it's also possible that the VI is already running in the UI thread and what makes it slow is that it has to wait on other stuff.

Here's one suggestion which may help - don't update the entire table. Instead, check the properties to see what the visible elements are and only update that area and the areas around it.

And another - assuming you're clearing the cells before painting them, use [-2,-2] as the ActiveCell to paint the entire table at once (although I'm assuming you already know that).

Another option - instead of doing the updates at the bowels of the application, send them off to a daemon VI dedicated only to that. That would mean that you can simply send a command to it and let the rest of the app proceed normally.

[tbd]

---

@tst wrote:

You could find out if context switching is to blame by setting the subVI to run in the UI thread. If it's faster, then the answer is yes. This will also answer your question to whether there's an advantage to doing this. You should note that it's also possible that the VI is already running in the UI thread and what makes it slow is that it has to wait on other stuff.

---

Want to try it, but haven't had time or access to the station. :(

---

Here's one suggestion which may help - don't update the entire table. Instead, check the properties to see what the visible elements are and only update that area and the areas around it.

And another - assuming you're clearing the cells before painting them, use [-2,-2] as the ActiveCell to paint the entire table at once (although I'm assuming you already know that).

Another option - instead of doing the updates at the bowels of the application, send them off to a daemon VI dedicated only to that. That would mean that you can simply send a command to it and let the rest of the app proceed normally.

---

This updating is being handled in a daemon which is updating many clusters and tables.  The daemon implements a "Register" function where an array of GUI controls - mostly cluster and table references - are passed.  Once "registered" updating happens automatically.

The problem occurs when initially populating a table.  To reduce the number of table-cell-color updates, the daemon checks whether a cell-value has changed - no value-change => no BG color-change.  Still, all the cells need to be colored initially - and there's the rub.

If the daemon updated parts of a Table (the visible parts), but not others, then it would have to either, remember which cells had been painted for efficiency, or always update all visible booleane/colors (if there were 30booleans to paint, our refresh rate would go from ~4hz to ~0.5Hz.)

It would certainly keep things simple if there was a way to solve the unreasonably slow cell-color updates.

I know updates by reference are "slower", but I suspect there's some sort of event contention or memory thrashing that might be avoided here. 

Yes, specifying index -2 to select all columns and/or rows is very convenient!

Thanks for the ideas - all food for thought.

Cheers.

[tbd]

Follow-up,

We made some changes.

Prior to changes, in a "data-acq" loop, we were reading raw data, updating a 2Darray of strings with formatted data, and writing the Table (2Darray) to the GUI by reference.

      We were seeing very slow response to user/GUI-events.

Tried

 - completely disabling color-updates (required update by reference each cell)

 - updating only visible portion of table

 - running Table-update loop (SubVI) in UI thread

 - loop parallelism,...  

 - timed loop on specific processor

UI response still pathetically slow when tables were being displayed/updated.

Changes

Instead of writing Table of [formatted] strings by reference, write raw-data (by reference) to GUI and process it in "value-changed" event - writing 2D strings to terminal.

Limit table-update to 2Hz. 

Were updating 10s of FP objects, mostly clusters, and while the cluster updates have worked great, table-updates were killing us.

In hindsight it seems obvious that the huge difference in amount of data being written by reference was part of the problem.

Clusters are updated by writing a packed/binary representation; tables by writing a 2Darray of strings.

Also, shifting the formatting and Table-update (including cell-color-property-update) to the UI thread seems to have improved performance.

Cheers.