07-30-2026 11:47 AM
@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.
07-30-2026 12:41 PM
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.)
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.
07-30-2026 03:36 PM
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.
07-30-2026 04:48 PM
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:
with this:
because when a property node of class "VI" doesn't have a reference wired, it refers to the current VI.
07-30-2026 11:14 PM
@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.)
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.
07-30-2026 11:43 PM - edited 07-30-2026 11:48 PM
@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.
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.
07-31-2026 03:24 AM
@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.
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.
07-31-2026 11:18 AM
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.
See if it can give you some ideas...
08-01-2026 03:52 PM
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.
08-01-2026 08:14 PM
@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.