Change background color of a table based on table cell values quickly.

[FrankHS]

When I was trying to find a solution for this problem of slow updates, I noticed that several people mentioned the problem of slow updates when changing the background color of a table with a property node. 

The numeric and string method uses an array instead of a table.

I just wrote a quick benchmark program. It does an array 2000 X 8 (16000 cells). Try it for yourself and see if you get similar results.

Numeric method                                                         1 to 2 milliseconds.

String method                                                             12 to 16 milliseconds    
Table, Property node with defer panel updates.         6.4 to 6.7 seconds

Table, Property node without defer panel updates.    19 to 22 seconds.  

The reason for the multiple for loops was that I wanted to demonstrate this so that if someone wanted to use it, they could copy the "String Method" or “Numeric Method” loops and the indicator into their code. It could have been done with 2 for loops.

The block diagram grid is on for the benchmark.

I don't understand about the panels being maximized. I can see them OK on my monitor.

[altenbach]

Thanks !

Yes, your method is definitely faster. 😄

However, what we need are better cosmetics. For example you should use borderless clusters and the frameless simple string and framless color box from the classic palette. Might even speed it up more. 😄 See attached modification.

What we really need is implementation of this idea.

---

@FrankHS wrote:

I don't understand about the panels being maximized. I can see them OK on my monitor.

---

If I open your VIs, but the front panel and diagram are maximised to the screen. If I restore the block diagram (=make it not maximised), the wirndow disappears and is located outside the left margin of my monitor. Do you use a multimonitor setup?

[LLindenbauer]

Dear all!

I was just benchmarking some solutions for zebra-striping a table (i.e. setting all even&odd rows to a specific color) and noticed that, for this specific use case, even more performance can be gained without Defer Frontpanel Update.

This is the classic idiom I have seen in a few threads on the forum, where a drastic (roughly 50-fold) speedup can be gained by bracketing it between two defer-update calls:

I did some experiments before hitting the forums and had a suspicion that the actual culprit here is the comparison & select, so I checked to see what happens when everything is constant:

This speeds up the process by a factor of about 2.5. What's more: 1) When this idiom is bracketed by defer-update, it does not benefit that much. Constant property without deferral is still faster than the variable idiom with deferred update. 2) Chaining the two loops together using dataflow does not change the execution speed at all. It seems that making the expressions constant inside the loop enabled the compiler to aggressively reduce the workload. It is nice to see the four different versions by @FrankHS, where having a dynamic array probably prevented this optimization.

I am using LabVIEW16 here, so I would be curious if this is still present in 2020+

[GerdW]

Hi L,

this is how it looks on my LV2020:

[Kevin_Price]

At first, I really thought you had the wrong diagnosis.  To me it looked like the speedup came simply because your method used 2 independent For loops that could run in parallel while each doing just 1/2 the work.  But I did some experiments:

- setting up "Iteration Parallelism" in the "select color, defer updates" method didn't speed it up any

- adding dataflow sequencing between the 2 loops in the "constant color, defer updates" didn't slow it down any

And THEN after scrutinizing the code a bit closer, I saw that the N for your two "constant color..." For loops was only 1/4 the size of the "select color..." methods.  You need to get rid of the extra divide-by-2's in the first frame of those sequences.

After that, I *did* still see a little speedup, but it was more like 15% here.

-Kevin P

[cstorey]

My results, LabVIEW 2020..interesting.

PN uses a Select T/F to decide on colour, whereas CPN uses 2 loops (odd/even) to specify each color. 

PN             0.1452

PN (DU)    0.0147 (about 10x faster!)

CPN          0.0105

CPN (DU) 0.0056 (about 2x faster)

Now, I found that table a bit small for a real world use case.  So I set it to display 20rows x 20columns and repeated.  It's here that Defer Front Panel Updates is important (when there's lots of front panel to update!) 

PN             1.032

PN (DU)     0.015 (~70x)

CPN           0.0288

CPN (DU)  0.00571 (~5x)

I also added changing the table visibility property to false, defering updates, process stripes, table visibility true and, renable updates and it was slightly faster yet.

Visibility Hide/Show 0.0041815 (~7)

Craig

Edit.. After seeing Kevin P's catch, the results are..

PN            1.03

PN (DU)   0.015    % compared to this

CP            0.0288

CP (DU)   0.0120  (25%)

VSH (DU) 0.0092   (63%)

You could argue that for BIG tables (5000) rows it would be an issue..but I don't think you would ever really do it for BIG tables.

PN          103.8

PN (DU) 1.27s

CP          1.21s

CP (DU) 1.40s

VSH       0.77s

[LLindenbauer]

Thanks to everyone for checking my work and further ideas!

I want to be able to display rather large datasets in a table, so this all helped me on the way to decide whether I need to implement my own MVC wrapper around a table element or if it can handle the tasks on its own.

I did not think about checking the visibility and it turns out that this gives the most speedup overall. Checking the visible size also showed that the constant version without deferring update becomes faster when the table is not in the viewport, e.g. by just scrolling it out of view or putting it in an inactive tabulator element. This removed the benefits from defer update and gave me a speedup due to the constant switch of about 1.8 when compared to the compounded statement (If the element is invisible, deferring the update does no longer speed up the task).

My main takeaway from this is that, if one can get away with it, pre-setting complex GUI-Elements is (- in hindsight unsurprisingly -) the most effective measure. And as an aside, that simplifying the inside of a loop may enable the compiler to speed it up drastically.

Best Regards,

Leo

[GerdW]

Hi Leo,

as your table doesn't show headers you might also use this approach:

[cstorey]

Nice.  Single loop, half the time.