Java reusing (static?) objects as temporary objects for performance

Question

I need to call methods of a class with multiple methods very often in a simulation loop.

Some of these methods need to access temporary objects for storing information in them. After leaving the method the stored data is not needed anymore. For example:

Class class {      
  method1() {
        ...
        SomeObject temp = new SomeObject();
       ...
  }

  method2() {
        ...
        SomeObject temp = new SomeObject();
        SomeObject temp2 = new SomeObject();
        ...
  }
}

I need to optimize as much as possible. The most expensive (removable) problem is that too many allocations happen. I assume it would be better not to allocate the space needed for those objects every time so I want to keep them.

Would it be more efficient to store them in a static way or not? Like:

Class class {
  private (static?) SomeObject temp;
  private (static?) SomeObject temp2;

  methods...
}

Or is there even a better way? Thank you for your help!

Edit based on answers: Not the memory footprint is the actual problem but the garbage collection cleaning up the mess. SomeObject is a Point2D-like class, nothing memory expensive (in my opinion). I am not sure whether it is better to use (eventually static) class level objects as placeholder or some more advanced method which I am not aware of.

Answer 1

I would be wary in this example of pre-mature optimization. There are downsides, typically, that it makes the code more complex (and complexity makes bugs more likely), harder to read, could introduce bugs, may not offer the speedup you expected, etc. For a simple object such as representing a 2D point coordinate, I wouldn't worry about re-use. Typically re-use gains the most benefit if you are either working with a large amount of memory, avoid lengthy expensive constructors, or are pulling object construction out of a tight loop that is frequently executed.

Some different strategies you could try:

Push responsiblity to caller One way would be to to have the caller pass in an object pre-initialized, making the method parameter final. However, whether this will work depends on what you need to do with the object.

Pointer to temporary object as method parameter Another way would be to have the caller pass as an object as a parameter that's purpose is essentially to be a pointer to an object where the method should do its temporary storage. I think this technique is more commonly used in C++, but works similarly, though sometimes shows up in places like graphics programming.

Object Pool One common way to reuse temporary objects is to use an object pool where objects are allocated from a fixed bank of "available" objects. This has some overhead, but if the objects are large, and frequently used for only short periods of time, such that memory fragmentation might be a concern, the overhead may be enough less to be worth considering.

Member Variable If you are not concerned about concurrent calls to the method (or have used synchronization to prevent such), you could emulate the C++ism of a "local static" variable, by creating a member variable of the class for your storage. It makes the code less readable and slightly more room to introduce accidental interference with other parts of your code using the variable, but lower overhead than an object pool, and does not require changes to your method signature. If you do this, you may optionally also wish to use the transient keyword on the variable as well to indicate the variable does not need to be serialized.

I would shy away from a static variable for the temporary unless the method is also static, because this may have a memory overhead for the entire time your program runs that is undesirable, and the same downsides as a member variable for this purpose x2 (multiple instances of the same class)

Answer 2

First, you need to make sure that you are really have this problem. The benefit of a Garbage Collector is that it takes care of all temporary objects automatically.

Anyways, suppose you run a single threaded application and you use at most MAX_OBJECTS at any giving time. One solution could be like this:

public class ObjectPool {

    private final int MAX_OBJECTS = 5;
    private final Object [] pool = new Object [MAX_OBJECTS];

    private int position = 0;

    public Object getObject() {

        // advance to the next object
        position = (position + 1) % MAX_OBJECTS;

        // check and create new object if needed
        if(pool[position] == null) {
            pool[position] = new Object();
        }

        // return next object
        return pool[position];
    }

    // make it a singleton
    private ObjectPool() {}
    private static final ObjectPool instance = new ObjectPool();
    public static ObjectPool getInstance() { return instance;}


}

And here is the usage example:

public class ObjectPoolTest {

public static void main(String[] args) {
    for(int n = 0; n < 6; n++) {
        Object o = ObjectPool.getInstance().getObject();
        System.out.println(o.hashCode());
    }
}

}

Here is the output:

0) 1660364311
1) 1340465859
2) 2106235183
3) 374283533
4) 603737068
5) 1660364311

You can notice that the first and the last numbers are the same - the MAX_OBJECTS + 1 iterations returns the same temporary object.

Answer 3

Keep in mind that temp and temp2 are not themselves objects, but variables pointing to an object of type SomeObject. The way you are planning to do it, the only difference would be that temp and temp2 would be instance variables instead of local variables. Calling

temp = new SomeObject();

Would still allocate a new SomeObject onto the heap.

Additionally, making them static or instance variables instead of local would cause the last assigned SomeObjects to be kept strongly reachable (as long as your class instance is in scope for instance variables), preventing them from being garbage collected until the variables are reassigned.

Optimizing in this way probably isn't effective. Currently, once temp and temp2 are out of scope, the SomeObjects they point to will be eligible for garbage collection.

If you're still interested in memory optimization, you will need to show what the SomeObject is in order to get advice as to how you could cache the information it's holding.

Answer 4

How large are these objects. It seems to me that you could have class level objects (not necessarily static. I'll come back to that). For SomeObject, you could have a method that purges its contents. When you are done using it in one place, call the method to purge its contents.

As far as static, will multiple callers use this class and have different values? If so, don't use static.