I would like to know is there any difference in performance between these two codes.
String sample="hello";
if(sample!=null)
{
if(!sample.equals(""))
{
// some code in here
}
}
or
String sample="hello";
if(sample!=null && !sample.equals(""))
{
// some code in here
}
As far as i have understood, in the first code, if sample is not null then only it will go in to the block. same is the case with 2nd piece of code.
What i would like to know is what is the difference in performance or better coding standards and why?
If you're asking about performance you should always measure. But No, there shouldn't be a difference. Besides, if that is your only performance-problematic code then I envy you, seriously.
As for coding standards. Less nesting is almost always nicer to read and follow. Which means that putting both in a single if, especially since they are related is preferrable. The pattern
if (check_foo_for_null && compare_foo)
is very common and thus much less surprising than another nested if.
EDIT: To back it up:
I have the two little methods:
static boolean x(String a) {
if (a != null && a.equals("Foo"))
return true;
else return false;
}
static boolean y(String a) {
if (a != null) {
if (a.equals("Foo")) {
return true;
} else return false;
} else return false;
}
which produce the following code:
static boolean x(java.lang.String);
Code:
0: aload_0
1: ifnull 15
4: aload_0
5: ldc #16 // String Foo
7: invokevirtual #21 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
10: ifeq 15
13: iconst_1
14: ireturn
15: iconst_0
16: ireturn
static boolean y(java.lang.String);
Code:
0: aload_0
1: ifnull 17
4: aload_0
5: ldc #16 // String Foo
7: invokevirtual #21 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
10: ifeq 15
13: iconst_1
14: ireturn
15: iconst_0
16: ireturn
17: iconst_0
18: ireturn
So apart from an extraneous else jump target the code is identical. If you don't even have the else:
static boolean z(String a) {
if (a != null) {
if (a.equals("Foo"))
return true;
return false;
}
then the result is really the same:
static boolean z(java.lang.String);
Code:
0: aload_0
1: ifnull 15
4: aload_0
5: ldc #16 // String Foo
7: invokevirtual #21 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
10: ifeq 15
13: iconst_1
14: ireturn
15: iconst_0
16: ireturn
As everyone else said, there shouldn't be any difference in preformance.
Small tip - equals almost always calls instanceof which returns false for null.
So writing:
if( !"".equals(foo)) {...}
does same check and is null-safe.
Bothe have no difference in terms of performance. Because in first case it checks one condition, if fails it does not enter inside. In 2nd case also, JVM checks the first condition, if it return false, then JVM will never go for 2nd check. As logical && operator will always false if first is false.
In terms of coding standard, I will choose 2nd option, as it has less number of coding lines.
Most likely the bytcode generated will be optimized to if(sample!=null && !sample.equals("")) since java performs an optimization in compile time.
If you are talking about the actual code you write it is better to have only one if. Since the structure of two if is more complex for the compiler (with no optimization). Although I have no empiric data to back this.
Related
I'm new to Java and i wanted to know if there is a difference between these 2 functions:
public static String function1(int x) {
String res = "";
if(x > 10)
res = "a";
else
res = "b";
return res;
}
and:
public static String function2(int x) {
if(x > 10)
return "a";
return "b";
}
and I'm not speaking on the length of the code, only efficiency.
The second version is in theory more efficient, decompiling to:
public static java.lang.String function1(int);
Code:
0: ldc #2 // String
2: astore_1
3: iload_0
4: bipush 10
6: if_icmple 12
9: ldc #3 // String a
11: areturn
12: ldc #4 // String b
14: areturn
whereas the version with the assignment decompiles to:
public static java.lang.String function1(int);
Code:
0: ldc #2 // String
2: astore_1
3: iload_0
4: bipush 10
6: if_icmple 15
9: ldc #3 // String a
11: astore_1
12: goto 18
15: ldc #4 // String b
17: astore_1
18: aload_1
19: areturn
where it can be seen that the additional variable is created and returned.
However in practise the difference in actual runtime performance should be negligible. The JIT compiler would (hopefully) optimise away the useless variable, and in any case unless the code was in a hot code path according to your profiler then this would certainly count as premature optimisation.
Both versions end up creating a string either "a" or "b" and return it out.
But version 2 is better in term of efficiency, which doesn't create an redundant empty string "" in memory.
What are the differences between this:
if(a && b)
{
//code
}
and this:
if(a)
{
if(b)
{
//code
}
}
From what I know b will only get evaluated in the first code block if a is true, and the second code block would be the same thing.
Are there any benefits of using one over the other? Code execution time? memory? etc.
They get compiled to the same bytecode. No performance difference.
Readability is the only difference. As a huge generalization, short-circuiting looks better but nesting is slightly clearer. It really boils down to the specific use case. I'd typically short-circuit.
I tried this out. Here's the code:
public class Test {
public static void main(String[] args) {
boolean a = 1>0;
boolean b = 0>1;
if (a && b)
System.out.println(5);
if (a)
if (b)
System.out.println(5);
}
}
This compiles to:
0: iconst_1
1: istore_1
2: iconst_0
3: istore_2
4: iload_1
5: ifeq 19
8: iload_2
9: ifeq 19
12: getstatic #2
15: iconst_5
16: invokevirtual #3
19: iload_1
20: ifeq 34
23: iload_2
24: ifeq 34
27: getstatic #2
30: iconst_5
31: invokevirtual #3
34: return
Note how this block repeats twice:
4: iload_1
5: ifeq 19
8: iload_2
9: ifeq 19
12: getstatic #2
15: iconst_5
16: invokevirtual #3
Same bytecode both times.
It makes a difference if you have an else associated with each if.
if(a && b)
{
//do something if both a and b evaluate to true
} else {
//do something if either of a or b is false
}
and this:
if(a)
{
if(b)
{
//do something if both a and b are true
} else {
//do something if only a is true
}
} else {
if(b)
{
//do something if only b is true
} else {
//do something if both a and b are false
}
}
If there is nothing in between two if statements in your second example then definitely first one is more cleaner and more readable.
But if there is a piece of code that could fit in between the two if conditions then only way is second example.
there shouldn't be a difference, but in readability I would prefer the first one, because it is less verbose and less indented.
I was curious to see how Java and Scala implement switches on strings:
class Java
{
public static int java(String s)
{
switch (s)
{
case "foo": return 1;
case "bar": return 2;
case "baz": return 3;
default: return 42;
}
}
}
object Scala {
def scala(s: String): Int = {
s match {
case "foo" => 1
case "bar" => 2
case "baz" => 3
case _ => 42
}
}
}
It seems like Java switches on the hashcode and then does a single string comparison:
0: aload_0
1: dup
2: astore_1
3: invokevirtual #16 // Method java/lang/String.hashCode:()I
6: lookupswitch { // 3
97299: 40
97307: 52
101574: 64
default: 82
}
40: aload_1
41: ldc #22 // String bar
43: invokevirtual #24 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
46: ifne 78
49: goto 82
52: aload_1
53: ldc #28 // String baz
55: invokevirtual #24 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
58: ifne 80
61: goto 82
64: aload_1
65: ldc #30 // String foo
67: invokevirtual #24 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
70: ifne 76
73: goto 82
76: iconst_1
77: ireturn
78: iconst_2
79: ireturn
80: iconst_3
81: ireturn
82: bipush 42
84: ireturn
In contrast, Scala seems to compare against all the cases:
0: aload_1
1: astore_2
2: ldc #16 // String foo
4: aload_2
5: invokevirtual #20 // Method java/lang/Object.equals:(Ljava/lang/Object;)Z
8: ifeq 16
11: iconst_1
12: istore_3
13: goto 47
16: ldc #22 // String bar
18: aload_2
19: invokevirtual #20 // Method java/lang/Object.equals:(Ljava/lang/Object;)Z
22: ifeq 30
25: iconst_2
26: istore_3
27: goto 47
30: ldc #24 // String baz
32: aload_2
33: invokevirtual #20 // Method java/lang/Object.equals:(Ljava/lang/Object;)Z
36: ifeq 44
39: iconst_3
40: istore_3
41: goto 47
44: bipush 42
46: istore_3
47: iload_3
48: ireturn
Is it possible to convince Scala to employ the hashcode trick? I would rather prefer an O(1) solution to an O(n) solution. In my real code, I need to compare against 33 possible keywords.
Definitely it seems that this case is a lack of optimization from the Scala compiler. Sure, the match construct is much (much much) powerful than the switch/case in Java, and it is a lot harder to optimize it, but it could detect these special cases in which a simple hash comparison would apply.
Also, I don't think this case will show many times in idiomatic Scala, because you always match with case classes that have some meaning apart from having different value.
I think the problem is that you're thinking about Scala from a Java point of view (I think you're also prematurely optimizing, but hey).
I would think that the solution you want is to instead memoize your mapping.
You've got a function that maps from String -> Int, right? So do this:
class Memoize1[-T, +R](f: T => R) extends (T => R) {
import scala.collection.mutable
private[this] val vals = mutable.Map.empty[T, R]
def apply(x: T): R = {
if (vals.contains(x)) {
vals(x)
}
else {
val y = f(x)
vals += ((x, y))
y
}
}
}
object Memoize1 {
def apply[T, R](f: T => R) = new Memoize1(f)
}
(this memoizing code is taken from here.
Then you can memoize your code like this:
object Scala {
def scala(s: String): Int = {
s match {
case "foo" => 1
case "bar" => 2
case "baz" => 3
case _ => 42
}
}
val memoed = Memoize1(Scala.scala)
val n = memoed("foo")
}
Tada! Now you're doing hash value comparisons. Although I will add that most memoization examples (this one included) are toys and will not survive most use cases. Real-world memoization should include an upper limit to the amount you're willing to cache, and in the case of your code where you have a tiny number of possible valid cases and a huge number of invalid cases, I would consider making a general class that pre-builds the map and has a specialized lookup that says, "in my cache, you win, not in my cache, default." which can be done very easily by tweaking the memoizer to take a List of input to precache and change the "not-in-cache" code to return a default.
This problem inspired me to learn about Scala macros, and I might as well share my solution.
Here is how I use the macro:
switch(s, 42, "foo", "bar", "baz")
The associated values are counted up automatically. If this is not what you want, you can change the implementation to accept ArrowAssocs instead, but this was way too complicated for me.
And here is how the macro is implemented:
import scala.language.experimental.macros
import scala.reflect.macros.blackbox.Context
import scala.collection.mutable.ListBuffer
object StringSwitch {
def switch(value: String, default: Long, cases: String*): Long =
macro switchImpl
def switchImpl(c: Context)(value: c.Expr[String], default: c.Expr[Long],
cases: c.Expr[String]*): c.Expr[Long] = {
import c.universe._
val buf = new ListBuffer[CaseDef]
var i = 0
for (x <- cases) {
x match {
case Expr(Literal(Constant(y))) =>
i += 1
buf += cq"${y.hashCode} => if ($x.equals($value)) $i else $default"
case _ => throw new AssertionError("string literal expected")
}
}
buf += cq"_ => $default"
c.Expr(Match(q"$value.hashCode", buf.toList))
}
}
Note that this solution does not handle hash collisions. Since the particular strings I care about in my actual problem do not collide, I didn't cross that particular bridge yet.
Given this Java code:
int fst = 5;
int snd = 6;
if(fst == snd)
do something;
I want to know how Java will compare equality for this case. Will it use an XOR operation to check equality?
Are you asking "what native machine code does this turn into?"? If so, the answer is "implementation-depdendent".
However, if you want to know what JVM bytecode is used, just take a look at the resulting .class file (use e.g. javap to disassemble it).
In case you are asking about the JVM, use the javap program.
public class A {
public static void main(String[] args) {
int a = 5;
System.out.println(5 == a);
}
}
Here is the disassembly:
public class A {
public A();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: iconst_5
1: istore_1
2: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
5: iconst_5
6: iload_1
7: if_icmpne 14
10: iconst_1
11: goto 15
14: iconst_0
15: invokevirtual #3 // Method java/io/PrintStream.println:(Z)V
18: return
}
In this case it optimized the branching a bit and used if_icmpne. In most cases, it will use if_icmpne or if_icmpeq.
if_icmpeq : if ints are equal, branch to instruction at branchoffset (signed short constructed from unsigned bytes branchbyte1 << 8 + branchbyte2)
if_icmpn : if ints are not equal, branch to instruction at branchoffset (signed short constructed from unsigned bytes branchbyte1 << 8 + branchbyte2)
In Java 7 a string object can be in the expression of a switch statement. Can someone explain the below statement from official documentation?
The Java compiler generates generally more efficient bytecode from switch statements that use String objects than from chained if-then-else statements.
Java Code
Having two versions of a class, e.g.
With if-then-else:
public class IfThenElseClass {
public static void main(String[] args) {
String str = "C";
if ("A".equals(str)) {
} else if ("B".equals(str)) {
} else if ("C".equals(str)) {
}
}
}
With switch:
public class SwitchClass {
public static void main(String[] args) {
String str = "C";
switch (str) {
case "A":
break;
case "B":
break;
case "C":
break;
}
}
}
Bytecode
Let's take a look at the bytecode. Getting the bytecode for if-then-else version:
Compiled from "CompileSwitch.java"
public class CompileSwitch {
public CompileSwitch();
Code:
0: aload_0
1: invokespecial #8 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: ldc #16 // String C
2: astore_1
3: ldc #18 // String A
5: aload_1
6: invokevirtual #20 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
9: ifne 28
12: ldc #26 // String B
14: aload_1
15: invokevirtual #20 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
18: ifne 28
21: ldc #16 // String C
23: aload_1
24: invokevirtual #20 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
27: pop
28: return
}
Getting the bytecode for switch version:
Compiled from "CompileSwitch.java"
public class CompileSwitch {
public CompileSwitch();
Code:
0: aload_0
1: invokespecial #8 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: ldc #16 // String C
2: astore_1
3: aload_1
4: dup
5: astore_2
6: invokevirtual #18 // Method java/lang/String.hashCode:()I
9: lookupswitch { // 3
65: 44
66: 56
67: 68
default: 77
}
44: aload_2
45: ldc #24 // String A
47: invokevirtual #26 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
50: ifne 77
53: goto 77
56: aload_2
57: ldc #30 // String B
59: invokevirtual #26 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
62: ifne 77
65: goto 77
68: aload_2
69: ldc #16 // String C
71: invokevirtual #26 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
74: ifne 77
77: return
}
Conclusion
In the first version compares the string by calling the equals method for each condition, until it is found.
In the second version is obtained first hashCode of the string. Then this is compared with the values hashCode each case. See the lookupswitch. If any of these values is repeated just happens to run the code for the case. Otherwise, call the equals method of the cases tied. This is much faster than ever call the equals method only.
switch on strings can be faster for the same reason why a lookup in a hash set of strings may be faster than a lookup in a list of strings: you can do a lookup in O(1) rather than in O(N), where N is the number of strings.
Recall that switch is more efficient than a chain of if-then-else statements because it is a calculated jump: an offset in code is calculated based on the value, and then the jump to that offset is executed. Java can pull a similar trick on strings using the mechanism similar to that employed in hash maps and hash sets.
It's more efficient something like:
switch(yourString) {
case "text1":
// your code
break;
case "text2":
// etc.
}
than the correspondent:
if (yourString.equals("text1")) {
// your code
} else if (yourString.equals("text2")) {
// etc.
}
i guess what it means, or what i understand is that the bytecode (when you compile your java class) that created from an switch statement using string is faster and more efficient than the bytecode that is created from an if-else statement using string. both can do the same job, bit switch is apparently more efficient.
switch (str) {
case "A":
// do something
break;
case "B":
// do something
break;
default:
//do something
break;
}
is better than
if(str.equals("A")) {
//do something
} else if(str-equals("B")) {
//do something
} else {
//do something
}