Does the Case List order have any impact on speed?

[jamiva]

As I was rearranging the case list order for a case structure with a String selector, it got me thinking-- Does the order make a difference in the speed of selection? There's got to be some finite time to compare the input string to each case until a match occurs.

If you have one String selector that has a very high probability, should it be at the top of the list rather than the bottom? Where should the default case be listed? Or does it really not matter because it is determined/optimized by the compiler.

I didn't see anything in the help. I did a quick search in the forum and to paraphrase the responses: "put it in a logical order to make it easier to understand". We are probably talking about nanoseconds, so unless you have a very tight loop, it won't make much of a difference anyway. I don't have a real need for an answer, just to satisfy my curiosity.

[Mark_Yedinak]

I can't say for certain but I would suspect that the comparisons are done from top to bottom, so the comparison for the first case in the order will occur first, then the second and so on. Unless you have some really large case structures or you are running them at a very high rate I doubt you would see much difference in performance though.

[ybalam · Accepted solution]

I'll second what Mark said. I benchmarked a case structure with fifty cases (okay, it might be a little bit of a slow day), that has to match a ten character string for each case and... With software timing, there's no difference in time between the first and last option, down to millisecond precision. Admittedly, I didn't really expect a delay with only fifty cases, but thought I'd give it a try anyway. 

I tested the middle option (case 25) as well, just in case it's smart enough to wrap around. Still no difference--I suspect you'd probably have to get a bewilderingly large case structure for it to start having a delay. 

Interesting question though! Thanks for the afternoon brain scratcher! 

[jamiva]

Thanks. I wasn't expect any responses on the Friday afternoon before the New Year's Holiday weekend.

My gut was telling me that there wouldn't be any significant difference one way or the other. So I'll just keep sorting the lists to make them easier to understand. Just wanted to hear what others thought.

[altenbach]

I doubt that the order matters, because the order is just a cosmetic property of the diagram and the compiler can do whatever it wants with it. I would expect the cases to be sorted behind the scenes to allow an efficient binary search, who knows? 😄

[Jacobson-ni]

---

---

Seemed like a fun scripting challenge so attached is a VI with a default case and then 1000 cases each defined by a unique 50 character string. In each cases is just a string constant that feeds to an output terminal and shows the case number. I did a bit of benchmarking to see how long it took to iterate 10,000,000 times and found some kind of interesting results. I don't want to spend the time to figure out tables in HTML so you'll have to deal with the terrible csv format with the first column being case number, second column as ms time of 10,000,000 iterations, and third being the first 5 characters of the case selector.

001, 1029ms, makpp...

003, 1002ms, alxin...  

998, 1068ms, natpw...

999, 0650ms, gtvfy...

If I sorted the cases it didn't seem to impact the iteration time. The last case was the only one that seemed to operate much faster and I could't even guess at why (my guess is that I messed up).

[altenbach]

Don't forget that each frame can have multiple cases, so sorting would not be possible anyway. (Example: case 1: ["ape", "zebra"], case 2: ["cow", "shark"], etc. (Behind the scenes, I would probably create a sorted list of strings, each pointing to a case index. Some might point to the same index).

Of course implementation could be more efficient with more information, e.g. if the cases have a vastly different chance of being called, one could sort by probability, but the compiler of course has no access to that information. Case structures don't typically have huge amount of cases so all this seems like overkill.

I'll have a look at your example.