How to avoid slow equals for interned objects?

Question

I'm creating a few rather big objects and many of them are duplicates. So I thought about using Guava's Interner for them and always work with the interned object only (i.e., each object gets interned just after creation).

It occurred to me that equals of those objects is rather slow (and gets used a lot) and that I actually never need it, as a.equals(b) is equivalent to a == b after interning. Unfortunately, the Interner itself uses equals so I have to override it for the single use.

I wonder if there's a simple way to have my equals and eat it?

Disclaimer: I know about the root of all evil and I'm not sure if optimization on this place is worth the effort. However, I'm interested if the above problem has a nice solution.

Brian Roach · Answer 1 · 2013-12-21T05:54:01.347

1

It depends on your use pattern as to where you want to take the performance hit.

If you're going to be doing a lot of comparisons after creating an object and you know you have a high occurrence of duplicates, then the flyweight pattern may make sense as all your post-creation comparisons can be done via reference equality.

The other thing to consider is space efficiency; you mention they're large objects. What's more important? If you're saving a ton of memory by pooling objects, that may be a win.

Profiling your code trying both approaches can also help you make that decision.

Edit to add: That said I'm surprised their interner is relying solely on equals(). In my head it would make much more sense to rely on hashcode() and only use equals() for collisions.

edited Dec 21 '13 at 05:54

answered Dec 21 '13 at 05:45

Brian Roach

76,169
12
136
161

I didn't mean the `Interner` relies *solely* on equals, it's a sort of hash map (actually the `MapMaker`'s map). But it's the *sole* reason I need `equals`. I'd prefer not to override equals because of its uses in other maps. – maaartinus Dec 21 '13 at 06:24
Right, that's a sane way to do it. That means the only time `equals()` is being called is on a hash collision, which means rarely given a decent `hashcode()` method (depending on the number of buckets). And if you're overriding `hashcode()` ... you need to be overriding `equals()` ... for the same purpose in other maps (::confused::) – Brian Roach Dec 21 '13 at 06:30

score 1 · Answer 2 · answered Jan 03 '14 at 09:14

1

If your equals method uses "a == b" internally, is that fast enough?

class BigObject {
  public boolean equals(Object o) {
    if(o == this) return true;
    if(o == null) return false;
    // a bunch of other stuff
  }
}

As a further step, you might consider wrapping "a bunch of other stuff" in a (private) method, which would encourage equals to be inlined. Hard to know when that stuff works, but ...

answered Jan 03 '14 at 09:14

Darren Gilroy

2,071
11
6

I don't think inlining `equals` will work in the relevant places (`HashMap#get` etc.) as there are other maps in the program and `equals` is heavily overloaded. – maaartinus Jan 03 '14 at 14:20

How to avoid slow equals for interned objects?

2 Answers2