Is it possible to create a new "Custom Conditional Statement" in java.

Here i am planning to create a new custom component for the switch statement to give better performance. The custom Switch control which i am planning to create will have only integer operators: example:

int i = SOMEVALUE;
Case 1: 
//Some Statement
Case 2: 
//Some Statement
Case 3: 
//Some Statement
Case 10000000: 
//Some Statement
//Some Statement

According to my knowledge the Switch condition will check in a particular order. If the actual value of the "i" variable is 9999999 then it has to check the case for 9999999 times but if we check it with some algorithms similar to binary search then its performance will be improved. Am I Right ??

If right then why don't we add this functionality to our programming language ? So why don't we create a "Custom Conditional Statement" something like "OrderedIntegerSwitch statement" , in which the value passed inside that switch should be an integer.

  • So the conclusion is introducing a new "ordered integer Switch" is not going to be better than the present SWITCH statements in all situation. Right ? – Dinesh Kumar Sep 7 '11 at 6:12
  • The conclusion is that you shouldn't be thinking of optimizing such a situation, and that much smarter and more knowledgeable people have already thought of anything you could possibly conceive. Rather fix your DESIGN that requires you to have that many cases in your switch statement. – Zoran Pavlovic Aug 28 '12 at 9:40
  • @ Zoran : Dude, "that much smarter and more knowledgeable people have already thought of anything you could possibly conceive". Ya i agree with my innocence, but if everybody thinks like that, then there won't be any inventions. – Dinesh Kumar Sep 4 '12 at 9:22

According to the JVM spec, a switch statement can be compiled to the bytecode instructions tableswitch or lookupswitch, depending on wether the cases of the switch are sparse.

tableswitch is O(1), while lookupswitch seems to be O(log n) (I guess it uses a binary search)

If you are curious about what instruction is chosen by your compiler for your piece of code, just decompile the bytecode and see if you find one instruction the other.

  • in the link which you suggested it is checking each and CASE in a order which the programmer mentions, wont that affect the performance for a huge number of cases ? – Dinesh Kumar Sep 7 '11 at 7:11
  • @user238284 : no it doesn't. For tableswitch, the order doesn't matter, since it is a lookup table. You can see it as an array containing, at each index that matches a case value, the instruction to jump to. For lookupswitch, the spec specifies that "the table instruction must be sorted by key". This allows a binary search for the JVM. – barjak Sep 7 '11 at 8:42
  • ya thank you .. sorry i dont have enough repudiation to vote you.. – Dinesh Kumar Sep 7 '11 at 9:07

You're not really right. A switch statement is typically not implemented as a series of if/elseif, but with a jump table, therefore it already executes in constant time, not in linear time. (This is why many languages already constrain the argument to switch to a smaller integral type than theoretically possible.)

To be sure, no compiler will generate a jump table with 1000000 entries if you switch over something that large, but there are similar tricks to get O(1) performance even if the naive approach would use too much space. Modern compilers almost always use some of these. Therefore it's unlikely you would be able to beat your language implementor with a homebrew solution.

  • But any way the flow should be in a particular sequence right ? How it can make its flow inexpensive without ordering those cases? – Dinesh Kumar Sep 6 '11 at 9:26
  • In a jump table, the order doesn't matter. Every case is O(1). When a more complicated solution is necessary, usually a compiler will not reorder cases because it has no basis on which to find more efficient orders. But a JIT compiler can and will analyse which case is used most often, and morph the code accordingly. – Kilian Foth Sep 6 '11 at 9:48

Besides the fact that compilers are already smart, do you really intend to type ten millions switch cases and their associated ten millions statements, and then hack a compiler for optimizing all of that?

You'd better put your efforts in changing your design. I can't imagine a real life situation where you need ten millions actions that are different enough not to be factorized.


Correct me if I'm wrong, but as far as I know the big difference between if..else statements and the switch ones, is that the first will check for each case one by one, until it finds the one that matches.

With a switch, followed by a break, you will instantly jump to the right case and end the statement afterwards.

I think what you say is true for the if..else statement, but not for the switch, which should be always faster with a large quantity of cases to check for.

  • No, if you consistently use else if instead of if, control flow will stop after one case has been executed. That's the point of else. – Kilian Foth Sep 6 '11 at 8:06
  • @Kilian: The code will still plow through all your conditions up to the first one that matches, while the case never does more than one check and a subsequent jump. Best case, your first if matches; then both are equally fast. Worst case, the first 999999 ifs don't match, and the case will be faster by a factor of 999999. – tdammers Sep 6 '11 at 8:36
  • @Kilian: right, I was clearly sleeping! corrected ;) – Jose Faeti Sep 6 '11 at 8:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.