01-21-2014 11:12 AM
@battler. wrote:
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?
If it makes the difference between your code working and not working then it is a good idea. But it really is a special case. Usually I would hold out hope that in time computers get faster and compilers get smarter. But, I do use knowledge I have about the expected input distribution to write the code accordingly the first time. With large data sets, LV often brings you quickly to a tough decision point, it is usually fast, but just not quite fast enough. Sometimes a little 25-50% boost is enough to move the boundary between what is doable and not doable.
My blackboxing suggests the following, but it is all guessing (and mostly for strings, numerics have constant comparison costs):
1) when n=2 you only need one equals comparison. Smoking fast, even for practically all strings.
2) when n>2 then it shifts to a binary search. Compiler sorts cases ahead of time. Compare to middle element first (that is the preferred case I see), but now you need to know < > or =, a more expensive operation, especially for strings. (I think this is the small hit I see when going from 2 cases to >2 cases). Worst case is now bounded by log2(# cases) comparisons instead of the # cases for a linear search. Very clever, but not optimal in a few cases. It does lead to some funny behavior which I have seen (adding dummy cases speeds things up for example).
As I think about it, I like the current behavior most of the time but it does seem like it would be nice to be able to tweak things. One possibility is to add a check mark to allow the display order to be the check order. No more binary search, but all comparisons are simple equality. Sometimes you are better off with a quick dumb search instead of a fancy search with more overhead.