LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Are Case Structures Slow??


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

0 Kudos
Message 11 of 21
(871 Views)

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.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 12 of 21
(861 Views)

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

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 13 of 21
(853 Views)

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

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 14 of 21
(850 Views)

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

 

Case Select.png

Message 15 of 21
(823 Views)

Debugging is not disabled.

 

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


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

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

0 Kudos
Message 17 of 21
(796 Views)

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.


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

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

 

Cameron

 

To err is human, but to really foul it up requires a computer.
The optimist believes we are in the best of all possible worlds - the pessimist fears this is true.
Profanity is the one language all programmers know best.
An expert is someone who has made all the possible mistakes.

To learn something about LabVIEW at no extra cost, work the online LabVIEW tutorial(s):

LabVIEW Unit 1 - Getting Started</ a>
Learn to Use LabVIEW with MyDAQ</ a>
0 Kudos
Message 19 of 21
(738 Views)

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

 

!rg.png

 

(I once called them Aztec pyramids)

Message 20 of 21
(711 Views)