Java - weight of instantiation

Question

Say I've got a very lightweight object:

public class Point {
  public int x;
  public int y;
  public Point(int ax, int ay){
    x = ax;
    y = ay;
  }
}

And I need to calculate distance very frequently - for example, during a scroll event on a mobile device that might fire several times per second.

If it keeps the code a little cleaner and more transparent to use new Point(a, b) each time, is the performance hit significant enough that I should consider caching a few references and update the member variables (as opposed to instantiation)?

score 5 · Answer 1 · edited Sep 02 '16 at 16:20

5

Personally I would not worry about instantiating these objects each time you need a point. While yes, it would be a tiny bit faster to cache a few, I agree that it would make the code less clean. Check out what this Java performance optimization book has to say about object creation costs: https://www.safaribooksonline.com/library/view/java-performance-tuning/0596000154/ch04.html

Basically, if an old Pentium II could create a million lightweight objects per second, then I don't think you have anything to worry about given today's MUCH faster processors/memory/etc.

edited Sep 02 '16 at 16:20

Captain Man

6,997
6
48
74

answered Feb 27 '12 at 05:49

nerdherd

2,508
2
24
40

+1 because i think i agree with you, but i think i should accept Shiplu's answer because that first sentence really sums it up. – momo Feb 27 '12 at 05:56
Yes, Shiplu summed it up nicely. Don't underestimate readability though. Given the negligible performance difference in this case I'd favor the more simple, readable solution. (Don't worry, that's not being lazy!) – nerdherd Feb 27 '12 at 06:02
1

yeah it's a difficult balance. in this case, where a fling gesture might check dimensions and position in very rapid succession, and on a handheld device without the guarantee of a massive processor, i deferred to performance in 2 spots, but generally I prefer "pretty" code over squeezing every last drop of power out of every line. Thanks for the responses. – momo Feb 27 '12 at 06:11
Good point, I wasn't focusing on the mobile aspect of this question. Where resources are limited any easy optimization certainly can't hurt! – nerdherd Feb 27 '12 at 06:22

score 2 · Answer 2 · answered Feb 27 '12 at 07:16

You may also wish to read the following resource which sums up the performance costs of allocation in modern JVMs as well as the impacts of using object pooling which has many similarities to the object reuse scheme that you are considering.

http://www.ibm.com/developerworks/java/library/j-jtp01274/index.html

Possible JVM optimizations such as those referred to by the following quote should be taken into consideration.

The JIT compiler can perform additional optimizations that can reduce the cost of object allocation to zero.

However, I am not familiar specifically with the JVM implementations used in today's mobile devices and they may very well not be on par with the implementations used on regular computers.

In either case, if at all possible, it is generally discouraged to perform premature optimizations unless there is obvious and needed performance gains associated with it.

All in all, unless you measure that the allocation costs of your Point objects is taking up too much time you should not sacrifice code quality to improve it further.

Shiplu Mokaddim · Accepted Answer · 2012-02-27T07:42:04.413

0

Updating previous instance will not allocate new memory but creating new instance will. Time to time jvm garbage collector will free memory. You don't have control over that. So it's always better to update existing instance unless you are keeping the history.

However you can always use a setter function.

public class Point {
  public int x;
  public int y;
  public Point(int ax, int ay){
   this.setXY(ax, ay);
  }
  public void setXY(int ax, int ay){]
    x = ax;
    y = ay;
  }
}

edited Feb 27 '12 at 07:42

answered Feb 27 '12 at 05:47

Shiplu Mokaddim

56,364
17
141
187

thanks. i already knew that, but seeing it in bold in a short, concise answer made me realize that i was just being lazy – momo Feb 27 '12 at 05:57
2

Making an object mutable (by providing a setter) is *not* always better, in fact there are many benefits to using immutable objects that could far overweigh the object creation cost. See here for some considerations: http://stackoverflow.com/a/3511336/372860 – oksayt Feb 27 '12 at 07:04

score -1 · Answer 4 · answered Feb 27 '12 at 05:45

You may use some instance variables instead of constructing objects on every call. This can effect your performance because this way you have to create and initialize the objects every time.

So its better to have a method call that updates the instance variables.

Java - weight of instantiation

4 Answers4