object pool OR Pass by reference the stateless objects

Question

I am repeatedly constructing a object which has 20 fields. This object is constructed and used by single thread.

I am planning to use a pool or construct the object once and pass it as parameter to the relevant methods. Once done, set all the fields to NULL. Reuse the same object again and again.

My question is, Will this approach will improve performance. As i could defer the creation of 100,000 objects (sometimes even more). But I need to set null to each field, will this overahead is comparitevely equal to the object creation.

Answer 1

I'd definitely try it out. Although is now "common knowledge" that one should not care about object creation, in fact there may be a lot of performance gained from using object pools and specific classes. For a file processing framework, I gained 5% read performance from pooling object[] objects.

Answer 2

Don't do that. Your micro-optimization may well be slower.

Object creation may have been a performance bottleneck around Java 1.0, but not anymore. The only reason to pool objects nowadays is for things that have significant resources associated with them, such as DB connections and threads.

Answer 3

I would recommend against using memory pools for anything but an external resource that is very expensive to build up, as a database connection or a thread. GC are very efficient dealing with short lived objects, so creating and removing (forgetting) objects is quite efficient.

There are associated costs to both creating new elements and maintaining old elements alive. The setting up of the fields (value assignment) will be similar in both cases, so what you have to compare are the other associated costs.

For a newly allocated object the second cost is, well, the memory allocation. Java managed memory environment with current garbage collectors is really efficient in allocating memory. Comparing to C/C++ where the OS needs to find the appropriate block of memory to assign, generational GC guarantee that memory is contiguous and as such allocation is really fast. In some Java 1.4 implementations it was meassure to take less than 10 CPU instructions. Deallocation of young objects (those that do not make it through the first GC run) is also fast: they are simply ignored --unless they have finalizers, which should be avoided as much as possible.

On the other hand, young objects that survive GC runs must be moved in each GC run from one part of memory to another. This can happen a couple of times before the object is considered old enough to move into the older generations, where chances are that it will move less (it can still move in a compacting GC runs on the older generations).

Another problem with long lived objects is that they cannot have references into younger generation objects. When this happens (assign new X() to an old object) the long lived object must be reassigned to the newest generation, and this can also imply costs, as it can require moving the object from the old generation region into the newer generation, and that will leave a hole in the old generation memory that could force moving objects in the next old generation GC run to compact memory.

Over all, the important part is that there is a lot of really smart people working in languages, compilers and garbage collectors. All those people will work to improve performance of the most common idioms, and trying to outsmart the system will probably get you out of path where things go soft and smooth.

Answer 4

If there is no expensive initialization that needs to be done on object creation, I wouldn't bother. Rely on the runtime to do memory management efficiently. If you eventually find that the bottleneck in your application is the actual allocation of the objects, you could try optimizing that further (although I doubt resetting all the fields to their default value will be faster, most likely it won't).

The general rule is: don't prematurely (micro) optimize :-)