LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

ListBox Color Change – Runtime Differences


@BertMcMahan wrote:

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..


That's interesting. Can you show the code?

 

The only slow part should be the property nodes and anything else should be fast. Maybe I don't undestand what you actually did.

0 Kudos
Message 11 of 21
(195 Views)

Sure, pic below and a 2020 version attached. I have no idea why it's so much faster- it was more of a curiosity to see how a Map would change things.

 

(I'll note that I am seeing semi inconsistent benchmarks. I didn't modify any execution priorities or anything on the code the OP uploaded, but I have seen "Langsam" take 7 seconds, then 750 ms, then 3.8 seconds, where it sort of settles into a rhythm and stays around 3.7-3.8 seconds.)

 

 

BertMcMahan_0-1785433000410.png

 

 

Note that I pre-generated a very small Map for only the labeled cases, so the Default pattern still gets called for anything not matching the specific terms (which doesn't appear to actually happen in this data set).

 

I would agree that the property nodes SHOULD be the only vaguely "slow" things, but that should mean that both of the OP's cases should be more or less the same in terms of timing. I would guess this is some compiler thing that's able to pre-compute some stuff for both OP's "Schnell" case and my Map-based case.

 

Let me know how it works on your computer though.

 

0 Kudos
Message 12 of 21
(181 Views)

Schnell and Bert have about the same execution time on my system.

 

I have found that Tables are typically faster than Listboxes. In addition, (it is more programming work, but for large tables, like the OP's 1000 element array), I found it faster to use a separate scrollbar and only populate the table based on what is shown on the display. When the user changes the scrollbar, I repopulate the table. It seems much faster. 

0 Kudos
Message 13 of 21
(162 Views)

I have no idea why, but the slowdown in the "Langsam" case seems to be coming from the case structure (with the color boxes).  I tried recreating that case structure from the case structure in the "Schnell" case, but it didn't fix the problem.

 

On a side note, you can replace this:  paul_a_cardinale_0-1785447993417.png

 

with this:  paul_a_cardinale_1-1785448021160.png

 

because when a property node of class "VI" doesn't have a reference wired, it refers to the current VI.

 

 

0 Kudos
Message 14 of 21
(149 Views)

@BertMcMahan wrote:

Sure, pic below and a 2020 version attached. I have no idea why it's so much faster- it was more of a curiosity to see how a Map would change things.

 

(I'll note that I am seeing semi inconsistent benchmarks. I didn't modify any execution priorities or anything on the code the OP uploaded, but I have seen "Langsam" take 7 seconds, then 750 ms, then 3.8 seconds, where it sort of settles into a rhythm and stays around 3.7-3.8 seconds.)

 

 

BertMcMahan_0-1785433000410.png

 

 

Note that I pre-generated a very small Map for only the labeled cases, so the Default pattern still gets called for anything not matching the specific terms (which doesn't appear to actually happen in this data set).

 

I would agree that the property nodes SHOULD be the only vaguely "slow" things, but that should mean that both of the OP's cases should be more or less the same in terms of timing. I would guess this is some compiler thing that's able to pre-compute some stuff for both OP's "Schnell" case and my Map-based case.

 

Let me know how it works on your computer though.

 


Thanks for your input. I have tried this also on my machine and get timing between 350ms up to 950ms. 

0 Kudos
Message 15 of 21
(133 Views)

@altenbach wrote:

@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.

 

altenbach_0-1785423976229.png

Thanks. I have set a Mode "vorherige Prüfung" where i make a map to find the maximum value. 

I have tried using the "Read Max and Min Keys" but i think it wont reconsider the value. Because i only got "Info" with 20 as Maximum and "Event" with 61 as minimum. But "Fehler" with 919 wont be given.

Anyway with this method i get timings around 100ms.


 

0 Kudos
Message 16 of 21
(126 Views)

@Valduril wrote:

@altenbach wrote:

@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.

 

altenbach_0-1785423976229.png

Thanks. I have set a Mode "vorherige Prüfung" where i make a map to find the maximum value. 

I have tried using the "Read Max and Min Keys" but i think it wont reconsider the value. Because i only got "Info" with 20 as Maximum and "Event" with 61 as minimum. But "Fehler" with 919 wont be given.

Anyway with this method i get timings around 100ms.


 


One error is present. Since the most data is removed but the indices reset to 0, the colors are assigned incorrectly. I still need to fix this.

0 Kudos
Message 17 of 21
(109 Views)

Here's what I would do to simplify the map handing and how to find the most frequent key.

There are some additional comments on the diagram.

 

altenbach_0-1785514567147.png

 

See if it can give you some ideas...

 

0 Kudos
Message 18 of 21
(85 Views)

The most frequent key should probably be done with a Mode.vi. that would put all the initial calculations into an optimized loop with all the debugging etc...on NI wheels that have already been invented.  (The Mode.vi is round enough and you are reinventing it!)

 

Some of your property nodes are incorrectly on the error wire.  You need to understand (and use) the ignore error option on property nodes.  Then stop the loop on error.  I'm willing to bet a few errors are not collected from the apply properties for loop.


"Should be" isn't "Is" -Jay
0 Kudos
Message 19 of 21
(59 Views)

@JÞB wrote:

Some of your property nodes are incorrectly on the error wire. ...

Without quoting some of a post, it is impossible to tell which post you are replying to.

 

0 Kudos
Message 20 of 21
(49 Views)