Impressive processing slow down due to UI refresh

[Kochise]

 Hello,

I'm experiencing a massive slow down in my test engine as

I refresh the display after each test. It is composed of a rather

'simple' array with a subtle change of color and boldness

to indicate failure or success of the test :

I also tried several things to determine which routine was

making the program almost crawl like a snail, here are my

results :

No UI refresh : 0m48s (same as Teststand with no UI update)

Array refresh but no page switch : 1m06s

Array refresh and page switch : 1m26s

There are 314 tests performed, so 314 redraw and optionally

314 page switch to reposition the view. Which gives the

following UI refresh costs :

Array refresh : 18s/314 = 57ms (just replacing one line, center up)

Page switch : 20s/314 = 64ms (right low corner)

Is that really the case ? Is there a way to make the UI redraw

quicker ? Create two separate loops/threads, one for doing

the test, one for refreshing the UI asynchronously ?

I could have understood for an array of cluster with different

widgets, but here I am 'just' displaying strings...

David Koch

[rolfk · Accepted solution]

Well multi-listbox control is a problem if your change causes access to muliple property node. For each property node LabVIEW normally does an UI refresh which does add up very quickly. Luckily there is a pretty easy way to fix that.

Use a Property Node for the current VI (just drop down a property node and change its class type to VI Server->VI Reference) to get the Panel reference. Then use another property node connected to your Panel Reference and select Defer Panel Update. Set this to true before you do your Listbox (and any other UI update) and set it to false afterwards.

[cubz]

Thanks for tip, rolfk

Could you tell how do you change class of the property node? I found only to wire the "This VI" reference first. Property node from the menu Functions > Application Control > Property node, has only the App class.

 

[rolfk]

There are many ways that lead to Rome. Your solution with the ThisVI reference is one. Right clicking on the header of the property node and selecting Select Class->VI Server->VI->VI another one. And last but not least, the picture I attached is a snippet. You should be able to drag it to your desktop and from there in your LabVIEW diagram.

[cubz]

A way to "Here-be-Lions" land better said for me 🙂 yet to conquer.

Select class under the right click on header was that, thx.

[Kochise]

---

rolfk a écrit :

Well multi-listbox control is a problem if your change causes access to muliple property node. For each property node LabVIEW normally does an UI refresh which does add up very quickly. Luckily there is a pretty easy way to fix that.

Use a Property Node for the current VI (just drop down a property node and change its class type to VI Server->VI Reference) to get the Panel reference. Then use another property node connected to your Panel Reference and select Defer Panel Update. Set this to true before you do your Listbox (and any other UI update) and set it to false afterwards.

---

Indeed that worked pretty well.

Placing the defered updates at strategic places, I made the

test a little bit quicker :

Before : 1m26-28s

After : 1m02-04s

Without display : 48-51s

I gained more than 20 seconds and I'm now 15 seconds

close to the test with no display at all. That's nice and I

know it would be hard to gain any further time slices.

The problem is that when the operator have to test like

300 cards, multiply this with 15 seconds and you waste

something like 1h15m in display operations. Hence the

need to have a less intrusive user interface but still be

able to display errors when needed.

Thanks for the tip.

David Koch

[BrainDrain]

Hi, I just found your question, when I was palying around with references for speeding up a graphical display.

As metioned before, the fastest update mechanism is using references. If you would write the information directly into the reference to your table display, the UI is updated instantaniously. Just have a lookat the screenshot below. The Vi on the left generates numbers and they are written into a property node of a reference. In my case the reference refers to an waveform chart that is part of an ohter application. Therefore, the reference  is handled by a global. If the value is changed on the left, the display immediatly updated on the right. Yes, there is no loop running on the right. But is does not matter. The display is updating even the vi is not executing as long the global contains the right reference!

To cut a long story short: if you directly write your array values into the appropriate reference, you don't have to wait for any UI update... so the update time should be the same as the array update time... without any further delay...

Best wishes,

Luke 

[rolfk]

No, no! The Value property is not the fastest way at all!

The fastest is the terminal and the local variable. Anything else will be way slower. Not a problem if you pass some value to a control every now and then, but definitely if you do it quickly inside a loop. There have been many posts about this and newer LabVIEW versions likely imporved here and there a few microseconds but the basic principle remains.

In addtion to the synchronous update of the value property which slows down everything significantly, property nodes are also executed in the UI thread which requires normally two context switches for each property node. Definitely not the best way to speed up your program. 

[Kochise]

Problem is, I do not copy the whole array in one time, but

update it one line at a time after the test had been executed.

While on the screenshot you see all lines executed, during

execution you see lines filling quickly as tests are being

executed. At the end you get the final result, passed or not.

So I needed something to 'pause' the redraw for a little

while, then unleash the beast once the UI have been fed

with enough data to display.

EDIT : I cannot copy the terminal everywhere so I use the

'Value' property node. It's NI's task to speed up access to

such common property node that mirror the effect of linking

the terminal directly (no double context switch for the 'default'

property)

QED.

David Koch

[drjdpowell]

Common technique to handle this kind of thing is to have the UI update at a lower rate than the tests, and possibly to have the UI in a separate parallel loop**.   Record your test info in a shift register structure, and only sometimes do a UI update (twice a second, say).

-- James

**Note: this later does not work if your business logic involves the UI thread (sometimes used with non-thread-safe dlls).

Added later: a third technique is to only display the visible lines, rather than filling the entire listbox.  Use a separate slider to allow the User to sellect which lines are visible (the User doesn't know the difference if you do it right).  This technique is highly scalable, as you can handle huge numbers of tests with no UI lag.