Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
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
up vote 5 down vote accepted

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.

share|improve this answer
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.

share|improve this answer
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.

share|improve this answer

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.

share|improve this answer
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 posting your answer, you agree to the privacy policy and terms of service.

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