LabVIEW
ListBox Color Change – Runtime Differences
Thank you! That's some good input.
@altenbach wrote:
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...
Many property nodes are unlikely to generate errors at runtime. Just applying some cosmetic properties does not require rigorous error handling compared to others. I tend to just wired the error out to the next structure to suppress automatic error handing.
In the example I gave, I focused on the required task. It is up to the recipient to dot the t's and cross the i's and potentially break things.... 😄
Note that an error could also occur if the panel reference is invalid. This would not happen with this idea implemented.
@Andrey_Dmitriev wrote:
@Yamaeda wrote:
That performance difference is quite strange! I wonder if anyone know why that is.
What I did instead was the following: I stored everything in an indexed database and displayed a ListBox without a scrollbar, containing only as many lines as could fit in the visible pane. The scrollbar was my own custom numeric vertical scrollbar placed next to the ListBox, so the user got the impression that it belonged to the ListBox, while in reality, under the hood, it did not.
Every time the user scrolled, I executed a query against the database, extracted only the portion of data that was actually visible on the screen (based on the scrollbar position), and displayed it with the appropriate colorization. This approach was extremely fast. Of course, I also handled the arrow keys, increment/decrement of the scroll bar and Page Up/Page Down functionality and so on.
As a bonus, I added the ability to filter the content, again using standard database queries. The result was very fast, but it took me about three weeks of hard work just to implement the viewer before everything worked like a charm (smooth, like Microsoft Access).
I don't think anyone here believes MCL's are fast. It's just that, for some reason, putting the property nodes inside the case selector with the constants has different timing than splitting them up. Not just different but drastically so.
Yes, we know that performance is not great and alternative approaches have been found.
The question still remains WHY nearly identical code ("Approach 1: and "Approach 2" in the OP question) show such a dramatic difference in speed. I made some wild guess above , but only somebody from the compiler team can probably give a definite answer. Very odd. 😄
@altenbach wrote:
Yes, we know that performance is not great and alternative approaches have been found.
The question still remains WHY nearly identical code ("Approach 1: and "Approach 2" in the OP question) show such a dramatic difference in speed. I made some wild guess above , but only somebody from the compiler team can probably give a definite answer. Very odd. 😄
Ah, this one... Oh, it’s quite simple — you already answered it yourself. Yes, it looks like constant folding. It’s sufficient to just surround the constant with a structure, and not only a case structure; a simple sequence is also enough. Then the code might slow down, by a factor of about 10–15 in this case:
Of course, there is no any rational reason why the second for-loop should be slower. It’s clearly a compiler issue (and sometimes hard to reproduce when the VI is created from scratch). Maybe someone from NI will take a look at this eventually, and someday it will get improved. In theory, I could run this under a debugger or profiler, but the problem is that this thread continuously switches to the UI thread on the property node (and this switch is probably being “optimized” when the constant is connected directly). In any case, this makes debugging a bit complicated. I’m not sure if it’s worth investing time here for a deeper investigation.
@Valduril wrote:Approach 1 ("Fast") takes 400 ms for 1,000 entries on our systems.
Approach 2 ("Slow") takes 17 seconds for the exact same data.
We are using LabVIEW 2022 Q3.
Thanks for any idea or tip.
I had to test it myself and just had an interesting result!
Version Schnell Langsam Yamaeda
LV24Q3 32b 240ms 11,04s 185ms
LV25Q3 64b 250ms 6,67s 175ms
By just moving the case structure to a 'pre-loop' i got it down to 175ms (188ms in LV24). Ignoring errors on the property node made it slightly slower in LV25, but improved it some in LV24. Deferring updates looses time at these speeds. Times are fluctuating pretty much, from 160-210 ms.
Adding a "only change if changed" got it down to 88ms.
