• Post Reply Bookmark Topic Watch Topic
  • New Topic

How == can increase performance as compared to equals()  RSS feed

 
Puspender Tanwar
Ranch Hand
Posts: 499
2
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In Effective JAVA by Joshua Bloch, when I was reading about static factory methods, there is a statement as follows:
The ability of static factory methods to return the same object from repeated invocations allows classes to maintain strict control over what instances exist at any time. Classes that do this are said to be instance-controlled. There are several reasons to write instance-controlled classes. Instance control allows a class to guarantee that it is a singleton (Item 3) or noninstantiable (Item 4). Also, it allows an immutable class (Item 15) to make the guarantee that no two equal instances exist: a.equals(b) if and only if a==b. If a class makes this guarantee, then its clients can use the == operator instead of the equals(Object) method, which may result in improved performance. Enum types (Item 30) provide this guarantee.


How do == increases the performance? In what context this performance is increased?
 
Campbell Ritchie
Marshal
Posts: 56533
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The increase is likely to be slight. There are two likely explanations for faster execution:-
  • 1: Less memory consumption and fewer objects. If instances of the class are immutable, there is no need to create two instances, nor to consume the memory the second instance would occupy. Factory methods like Integer#valueOf(int) make use of that, which is why the Integer(int) constructor is now deprecated.
  • 2: Avoiding method calls; if you can use == that might confirm equality in one clock cycle, rather than using equals(). You must be careful to verify that only one object per value is created, otherwise == will give you incorrect results. If your equals() method starts return obj == this ||..., or similar, the enhancement is likely to be slight.
  •  
    Puspender Tanwar
    Ranch Hand
    Posts: 499
    2
    Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Campbell Ritchie wrote:The increase is likely to be slight. There are two likely explanations for faster execution:-
  • 1: Less memory consumption and fewer objects.
  • 2: Avoiding method calls; if you can use == that might confirm equality in one clock cycle, rather than using equals(). You must be careful to verify that only one object per value is created, otherwise == will give you incorrect results. If your equals() method starts return obj == this ||..., or similar, the enhancement is likely to be slight.

  • If I understand it with the java.lang.String's equals(Object ob) method :
    the local variables and arrays are cosuming some memory, so may decrease the performance. And the iteration to arrays is increasing the clock cycle which also decreases the performance. Am I right on this?
     
    Campbell Ritchie
    Marshal
    Posts: 56533
    172
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Puspender Tanwar wrote:. . . String[/javadoc]'s equals(Object ob) method . . . the local variables and arrays are cosuming some memory, so may decrease the performance. And the iteration to arrays is increasing the clock cycle which also decreases the performance. Am I right on this?
    The local variabes only occupy a small amount of memory on the stack: one 4‑byte w‍ord each for the two ints and a w‍ord each for the two array references (remember only the reference is copied onto the stack, since arrays are objects). Yes, it is then necessary to iterate the two arrays; how else will you determine whether two objects for which (obj1 == obj2) returns false contain exactly the same data? Yes, the == operator can be executed in constant time and the full‑blown equals() method runs in linear time. So, yes there is slower performance, but unless you can ensure that for a correctly written equals() method, where Object represents the set of all objects,
    x, y • {x, y} ⊆ Object ⇒ (x == yx.equals(y))
    you will require the greater power of overridden equals() to identify two objects with the same contents. [As Bloch says, elements in an enum do fulfil the requirements of that quantification.] So you need the additional time and memory expenditure to obtain that greater power. As you will see in the equals() method you showed (some very old‑fashioned code there, with C style written all over it), line 2 short‑circuits the method so most of it isn't executed in the special case where it is comparing an object to itself. That is why you sh‍ould always start an equals() method by using obj == this or similar.
     
    Junilu Lacar
    Sheriff
    Posts: 11477
    180
    Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Just a nitpick on how you phrased your question: unless you're fiddling with hardware settings, there's no "increasing of clock cycles" involved here. A clock cycle is more or less a fixed period of time so when it comes to this kind of discussion, you should think of operations requiring fewer or greater number of clock cycles to complete.

    The key concepts to keep in mind are immutability and reference equality. If instances of a class are immutable, then it may be appropriate to use reference equality when comparing different instances. This applies to things like enum values since each unique value of an enum will only have one instance created. Immutability, however, does not guarantee that reference equality is appropriate to use; it depends on how the class is designed to manage instances and what the semantics of equals() vs. == are.
     
    Puspender Tanwar
    Ranch Hand
    Posts: 499
    2
    Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks, Campbell & Junilu
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!