ListBox Color Change – Runtime Differences

[Valduril]

Hello,

we are trying to use a list box as a message log to display different types of messages. The messages are color-coded based on the data message type.

Currently, we have two different approaches for updating the cells.

Approach 1 ("Fast") takes 400 ms for 1,000 entries on our systems.

FAST Approach

Approach 2 ("Slow") takes 17 seconds for the exact same data.

SLOW Approach

Where is this massive difference coming from?

If we are using the Panel Property "Defer Panel Updates" we can drop the time on approach 2 to 970ms. But still it's two times slower then approach 1.

We are using LabVIEW 2022 Q3.

Thanks for any idea or tip.

[altenbach]

Consider to do a "save for previous" (2020 or below) and attach the downcoverted version so more can have a look at your VI.

Where is the listbox (caller? same VI?)

What is the timing of version 1 if you defer panel updates?

Is debugging disabled (I guess not, since you show probes on the picture)

Why not use a single property node with all three items?

[GerdW]

Hi Valduril,

while downconverting the VI please include a 3rd test where you "defer panel updates" before manipulating the listbox…

[Valduril]

Hello Altenbach and GerdW.

The version 2020 is attached and 2 new cases are added. 

- Case 3: defer panel updates on approach 2 -> now with an own case the timing differs around 550ms (not 970ms as before)

-  Case 4: same as 3 but in one property Node -> timing is the same as Case 3

The Listbox is in the same VI in this example.

The timing in version 1 differs around 400ms if defer panel Updates are used.

If debugging is disabled the timing jumps to 550-650ms in version 1.

When enabled the timing differs around 400ms.

[altenbach]

---

@Valduril wrote:

The version 2020 is attached and 2 new cases are added. 

---

Where?

[Valduril]

---

@altenbach wrote:

---

@Valduril wrote:

The version 2020 is attached and 2 new cases are added. 

---

Where?

---

in the first Post

[altenbach]

Thanks,

I actually made a quick mockup in the meantime, see attached.

What you should do is find out which category is most common (red in your case!), and color all cells (-2, -2] with its colors before the loop, then only color the others in the FOR loop.

[altenbach]

---

@altenbach wrote:

What you should do is find out which category is most common (red in your case!), and color all cells (-2, -2] with its colors before the loop, then only color the others in the FOR loop.

---

Here's a quick and dirty modification to show what I mean (<<20ms in my testing on your dataset).

Of course in a real scenario, you need to detect the most common color programmatically.

[BertMcMahan]

I got a 10-20x speedup on the "Langsam" code by enabling For Loop paralellism.

Out of curiosity I also tried replacing the Case structure with a pre-generated Map. That got me a 50x speedup, without using parallelism. Adding parallelism to that got me another 25% gain or so, but not a ton.

Deferring panel updates is also huge, as you mentioned. Langsam goes from 3.8 seconds to 220 ms. Adding parallelism doesn't help here for whatever reason.

Deferring panel updates with the Map seemed to make it take a little longer, but there is something weird going on with subsequent runs- I think the benchmark is reusing some old data.

Anyway- my fastest improvement is a Map + Parallel For Loop, which got my time from ~3.9 seconds to 125 ms.

I also tried this with Altenbach's solution. For some reason, his VI varied a lot on my machine, sometimes taking 12 ms and other times 80 ms. Adding a Map didn't seem to change much, if anything.

[altenbach]

To dig into your real question why "Schnell" is so much faster. I don't know!

(Maybe has to do with constant folding if all wired color properties are constants but that would be surprising)