Are Case Structures Slow??

[battler.]

---

@Darin.K wrote:

---

---

---

There are really good reasons to use enums instead of strings, speed is way down on that list.

---

Can you point me in the direction of a good thread explaining the benefits of enum over string based?

---

As to the minimal nesting, what I suggest is the following example:

If I know there are three strings I am looking for 'abc' 'def' and 'ghi', and I know that 'abc' is going to be coming 90% of the time then I will create a case structure with two cases 'abc' and default'.  Iniside the default case I put a second case structure which covers the remaining cases (def, ghi and default).  Rarely I may know that 'def' is 99% of the remaining cases so I may nest again (def + default), but it is rare to need more than a couple layers of nesting.

---

Is nesting of case structures as suggested really a good idea?  Coding like this is a significant undertaking.  I do a lot of processing of large datasets (arrays and clusters) and require speed.  Nesting like this would make the code less understandable.  Does the LV compiler not handle this as you've suggested or is it simply impossible for it to predict?

[Mark_Yedinak]

From a readability stand point you can make a subVI out of the nested case if you require multiple layers of nested case statements. I am not sure if the overhead of the subVI call would significantly impact your performance. You can also inline the subVIs so that should prevent the performance hit but it would aid in code readability.

[Yamaeda]

---

RavensFan wrote:

Since a n>2 case structure is similar to a Case Select statement in C or other text-based languages, I assume it evaluates each case in turn and will stop checking conditions once it finds the Case that is true.  Is that what you are saying as well?

Since LabVIEW doesn't have any obvious method of determining which case it compares against first, is there something that determines the order?  Will it make the conditional comparisons in order based on the order of the frames within the case structure?  Will it start executing case 0 of the structure if that happens to be True any earlier than it would execute case 192 (if you had a case structure with that many cases) if that happened to be True?  In other words, will reordering the cases within the case structure have any effect, however subtle, on execution time?

---

I remember a comment from a NI developer in these forums that mentioned that the most used event should be placed first in an event structure if optimizing for speed, and i assume case structures as well as event structures look through their cases in order. (Must test this)

/Y

[Yamaeda]

Yes, order makes difference. Check this VI, reorder the case by moving Default to first or last yields me 40ms difference.

/Y

[johnsold]

It may be more complicated than simple order. I created separate subVIs for each default case and then ran all of them inside a loop.The graph shows the times against default case.  I created the subVIs very quickly by Save As and modifying the default case. I did not go back and check, so there might be an error or two. But it certainly appears that the time differences are not given by any obvious or simple relationship.

Lynn

[JÞB]

Debugging is not disabled.

Lynn, I think I finally found a mistake you made.

[johnsold]

I always forget that.  I make enough errors that it is always good for me to leave debugging on.  Then everything constant folds and the times go to zero.  Change the 1E8 constant to a control?

Lynn

[JÞB]

Yes, That compiler is getting pretty smart.  Changing the 1e8 constant to a control should unfold your code and yes, that would be folded but not paralizable (Parallilizable?)

Benchmarking "In-The-Dirt" is really tricky.  I'm fairly certain that you'll also need to use the hi res timer and be VERY careful about FPs in memory to get meaningful results.

Proving earlier comments on this thread the the difference in case structure execution for default is so miniscule as to make it more academic than practical to code around.

[camerond]

---

@battler. wrote:

---

@Darin.K wrote:

---

As to the minimal nesting, what I suggest is the following example:

If I know there are three strings I am looking for 'abc' 'def' and 'ghi', and I know that 'abc' is going to be coming 90% of the time then I will create a case structure with two cases 'abc' and default'.  Iniside the default case I put a second case structure which covers the remaining cases (def, ghi and default).  Rarely I may know that 'def' is 99% of the remaining cases so I may nest again (def + default), but it is rare to need more than a couple layers of nesting.

---

Is nesting of case structures as suggested really a good idea?  Coding like this is a significant undertaking.  I do a lot of processing of large datasets (arrays and clusters) and require speed.  Nesting like this would make the code less understandable.  Does the LV compiler not handle this as you've suggested or is it simply impossible for it to predict?

---

IMHO, nested case structures are often quite readable, they run just like the text-base analogy, but are easier to follow by just flipping the case from one to another, your visible paths change and you don't have to mark down all the "if-then-else-if-then- ..." code.

(now  commenting on Mark's suggestion) Mark, changing things into subVIs in this situation, unless there is a lot of code to follow, just makes things a bit more unwieldy for me because then I have to cover up real estate with the subVI's code (I'd love to have 4 big screens like some do, but it just isn't in the cards). I usually just do the selection of actions to do in this (sub)VI, then leave the resulting action to the next one in a state machine. That way I can only make one big mistake in each subVI .

Cameron

[altenbach]

At one point we start building Mesoamerican structures, though (seen here). 😄

(I once called them Aztec pyramids)