Charles Oliver Nutter schrieb:

ok, let us do less speculation and more concrete talk. There are three ways to implement a switch case.

1) direkt jump (tableswitch, O(1)): We calculate an offsett adress depending on the switch value. This will allow us to directly jump to our goal, but requires that the case values are not too far scattered.

2) binary search (lookupswitch, O(logn)): We assume we have a sorted list of case values and can do a binary search on this list by comparing the case vale and the switch value.

3) if-else-cascade (O(n)): we go step by step through each case value.

From looking only at the numbers here the tableswitch seems to be the best choice, but the restrictions on my data are very high. not to forget that I need to calculate the offset. usually this is pretty fast, but should not be forgotten. the lookupswitch is less restrictive, and does not really need a number to work. But it needs a sorted List with case-value/jump-goal pairs. Theoretically you could sort the list before doing the lookup, but what is the point in doing a O(nlogn) action instead of a O(n) action? Not to forget, that if you sort by using the case values directly you might cause side effects, that where intended to be triggered only for matches. So unless you can avoid the side effects and cache the list (for example let the compiler do the sorting if possible) this version might be worse than the cascade. In Java a value compatible with int is required, so it is very easy. But because of the calculation a lookupswitch of size 1 might be faster than a tableswitch of size 1. Well, probably as fast as a if-else then. How many cases are needed to make the tableswitch really faster depends on how much time it takes to calculate the offset.

Now I don't know about Ruby, but in Groovy we have a isCase method, that will be called to see if a case matches. This automatically means we can not do the switch constructs, unless we know the case values before and there is a sorting that matches them. So a switch over a character where I only match with character constants could be done quite easily with 1) or 2), but the general case can not. A case may in Groovy also include ranges, closures or regexp... that's not good for sorting and not good for your cases if they depend on a certain order in your code. For example:

switch (x) { case Integer: println "I am Integer" break; case Object: println "I am Object" break; case default: println "Hell, what am I?" }

if you use this code in Groovy with for example 5 as value for x, then it must print the Integer text. My sorting would now have to know this! Put an interfaces in there and you get a hell of doing a correct sorting.

So the short answer to why Groovy does not do this is: because it is not trivial to do for something else than numbers.

When talking about the O-Notation we always talk about very big n, our usual used n are not that big. So the three have to be tested in real world cases to see which of them is the fastest. And which of them it is might depend on your VM, your CPU and the mood of the weather. But all in all... will the if-else be much slower than the other two? What for example if my second case would match, but I have a very slow isCase implementation on the median of my search list? The call to isCase on median may outrank x other isCase calls on the case values before.

So the longer answer is: In real world applications the lookup and table switches might not be much faster than a normal if-else, because there are not enough values to make a real difference. It makes a difference only in certain cases and these are currently no uses cases for Groovy. so we may optimize it in the future, but currently there is no need.

bye blackdrag