From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
in conditional structure, how do I set what it tested first?
@EngrStudent wrote:
I have a case structure. Whether it is case-switch or if-then, it is a conditional selector of which subset of code to run.
It's not a case-switch nor an if-then. It's a case structure 
.
Not a case-switch, as a switch (in C) allows multiple matches. Not an if then, as there's always one case that matches.
@EngrStudent wrote:
I have a lot of processing to do with my code, so I want to make sure it runs well, and building that in as I go is much less expensive than coming back to optimize.
Not per se. If you don't need to optimize at all, it's less expensive to not optimize at all than to do it as you go.
"Optimize when needed" goes a long way...
@EngrStudent wrote:
I would like to make a "default", not in the sense of failing to pay on a loan, but in the sense of the first case tested, so that I can put the most common case there, and not have to look through multiple conditions tens of millions of times.
What is the way to specify which option in a case is tested first, second, etcetera?
The compiler will probably prefer the first case to test first. Probably the tests are executed in order... There's no guarantee AFAIK though. These are not facts! It makes sense as there's no reason the compiler would change it. But it could just as easy always reverse the order... You'd need extensive bench testing to prove it.
You can order the cases by right clicking the CS and selecting "reorder cases".
If you want to be absolutely sure, you can always nest the cases. So a positive test a executes A, a negative (default case) has a new case testing for b and executing B (positive) or testing for c (negative). Seems like a lot of work, and inflexibility as additional cost. I'd have to be sure it makes a difference before I'd do it like that. Note that it might make things slower. Always, just in the worse case, or somewhere in between.
I doubt it will make much difference in practice. It might, but it will be a corner case (lots of compare, and not a lot of anything else).
I wander if there's a better solution. For instance using a map, or an array as LUT... OO Polymorphism comes to mind, but we'd need much more detail.
Search LabVIEW like a graph! 
Reminds me of the old days where you had to make an assembler programs because it was fast. Until the C compilers got so smart (and assembler too complex) they'd beat pretty much everyone. Some 20 years ago.
At least try the code first. "Millions of tests" might take just a fraction of a second.
And if the total algorithm takes too long, search for (what is proven to be) the most consuming part. This is often a surprise.
Traditionally, optimizing the algorithm gets you orders of magnitude more speed that optimizing parts.
@EngrStudent wrote:
@Weibe@CARYA
There aren't a lot of those laying around in LabVIEW. Parallelize. Use some fancy libraries for high-speed stuff. I'd like to think about going gpu, but I haven't done that before in LabVIEW so banking on that is risky.
There's no telling without seeing the code.
@EngrStudent wrote:
@Wiebe@CARYA
I have code that takes 6 seconds to run, and I need to run a few hundred thousand times.
BTW that sounds like a perfect test case.
Change one case structure order to the worse (presumed) order, time the execution. Change it to best order. See if it makes a difference.
wiebe@CARYA wrote:
@EngrStudent wrote:
I have a case structure. Whether it is case-switch or if-then, it is a conditional selector of which subset of code to run.
It's not a case-switch nor an if-then. It's a case structure
Actually it is either a switch or an if-then, and it does make a difference. The two-choice (if-then-else) case structure is significantly faster than a case structure with three or more options. Not just three cases, as soon as you add a third choice, even by using a list for the second case, you get a slowdown.
This means that nesting case structures is in fact a bit faster than a single case with multiple selections. Now, before you build case structure pyramids, you encounter my "WTF rule". If you optimize code to shave a few milliseconds, then the number of times you run that code had better be high enough, otherwise all of the time you "saved" will lost when you go to edit the code later and stop to say "What the f****?"
On the other hand, if you know something about your data, then it would be foolish not to use it. If you know one case is going to be chosen 99% of the time, then I would suggest a case structure that handles only that case and put the checks for the other 1% in the default case.
I don't have the code at the moment, but I do have some benchmark results. I created an array of strings which are either "True" or "False", and then I process the array in two different loops. In the flat case, there is a single case structure with cases "True","False",Default. This is the switch variety case structure. In the second loop I have an outer case structure with cases "True", Default. Nested inside the first Default case is a second case structure with cases "False", Default. This is analogous to two if-then-else cases. Here is the data:
The nested case is about 4X faster. Does this mean it will speed up your code 4X? Only if your code is like my benchmark, specifically designed so that the comparisons are the dominant operation. I highly doubt that your code is being bottle-necked by case structure comparisons.
