-2

I am working one java project . I am wondering

if (a) {
  // ...
} else if (b) {
  // ...
} else if (c) {
  // ...
}

or

if (a) {
  // ...
}
if (b) {
  // ...
}
if (c) {
  // ...
}

//I m sending 10 parameter like this which is the fast way problem of above code in else if I send last parameter it will check all then it will go last. so which is fast which is slow

Andy Turner
  • 137,514
  • 11
  • 162
  • 243
  • 2
    `else if` is generally faster since it avoids an extra check (unless you have an early return). But it has nothing to do with time complexity. – shmosel Feb 24 '17 at 08:45
  • Both are really ugly. I'd go for option 3. – Kayaman Feb 24 '17 at 08:46
  • 1
    You wouldn't really indent your code like that, would you? – khelwood Feb 24 '17 at 08:48
  • 1
    They are different, in general: in case 1, only one block is executed; in case 2, all blocks for which the condition is true are executed (assuming execution completes normally in each block). – Andy Turner Feb 24 '17 at 08:53

4 Answers4

3

The real answer here is: unless you identified a real performance problem; you do not worry about "performance" issues within your code.

Meaning: you did some profiling and found that a certain piece of code that is called many millions of time during a short period of time takes "too much" time. Then you would probably start by writing small examples, trying to do reasonable benchmarking to enhance your solution to meet some "target" performance.

But be assured that the difference between switch/if/if-else is in the range of nano-seconds; and you have no idea what the just-in-time-compiler is doing to your code anyway. To the contrary: the JIT is great about optimizing "normal, ordinary" code. When you start to be "clever" and "optimize" on the java source code level; chances are that you make it harder for the JIT to deal with your code. So, in the end; your java code looks "faster"; but the real execution time is worse than before.

Thus: you focus on writing code that is readable. And alone the fact that you talk about "10 parameters" that need to be treated is bad practice.

Long story short: focus on good design; for example based on SOLID principles (of course avoiding real performance pitfalls). That will allow you to change your implementation later on; in case you are running into real performance issues.

As of now, you are wasting your energy on the wrong topic.

Community
  • 1
  • 1
GhostCat
  • 137,827
  • 25
  • 176
  • 248
0

Normally performance goes in order of:

  • switch statement
  • Lookup table via array or dictionary structure
  • Chained if, else if
  • Pile of independent if statements.

The switch is ideal if you can swing it, that can be optimized more aggressively. The series of independent if statements is the worst performer, each of those must be evaluated. Your else if version can perform better if you order them correctly and avoid doing expensive but infrequently exercised branches first.

tadman
  • 208,517
  • 23
  • 234
  • 262
0

You worry time execution about 10 if else if or if statements ?
If you have not noticed any concrete problems with time execution about them you should not even consider them. These are very very very lightweight instructions.

1) Two shown codes doesn't perform the same thing.
With if else if, the statements are related. So as soon as one condition is true, the following else if statements are not executed.
With a series if, it is not the case as statements are not coupled.

So you could have a distinct behavior according to the one or the second one way.

2) Clearly both solutions are not readable and error prone.

Rather worry about readability and maintainability of the code. Having 10 parameters in a method and testing them in this way is not desirable.

davidxxx
  • 125,838
  • 23
  • 214
  • 215
0

As noted by GhostCat, the most important thing is to write readable code. Once I formatted your code, it became a lot more apparent that your two approaches have different semantics:

  1. In the first approach, only one of those blocks is executed. It doesn't matter if b is true when a is true: only the block associated with the a condition is executed.

    Moreover, if b is actually an expression with side effects (like an assignment or a call to a method with side effects), b is never evaluated, so that side effect doesn't happen.

  2. In the second approach, all blocks are executed. If both a and b are true, both of their associated blocks are executed.

So, you need to pick the one with the more appropriate behavior.

For example, given:

boolean a() { System.out.println("a()"); return true; }
boolean b() { System.out.println("b()"); return true; }

Code using approach 1:

if (a()) {
  /* ... */
} else if (b()) {
  /* ... */
}

Output:

a()

Code using approach 2:

if (a()) {
  /* ... */
}
if (b()) {
  /* ... */
}

Output:

a()
b()
Community
  • 1
  • 1
Andy Turner
  • 137,514
  • 11
  • 162
  • 243