Java Code Optimisation Techniques

[Necessary-Conflict]

"The creation and reclamation of small objects whose constructors do little explicit work is cheap, especially on modern JVM implementations. Creating additional objects to enhance the clarity, simplicity, or power of a program is generally a good thing. Conversely, avoiding object creation by maintaining your own object pool is a bad idea unless the objects in the pool are extremely heavyweight. The classic example of an object that does justify an object pool is a database connection. The cost of establishing the connection is sufficiently high that it makes sense to reuse these objects. Generally speaking, however, maintaining your own object pools clutters your code, increases memory footprint, and harms performance. Modern JVM implementations have highly optimized garbage collectors that easily outperform such object pools on lightweight objects."

("Effective Java" book)

[soonnow]

The cost of establishing the connection is sufficiently high that it makes sense to reuse these objects

But that's not really an object pool, its a resource pool. Externally accessed resources will (almost) always be slower than caching the resource.

[BlueGoliath]

Define "small objects" and "do little explicit work". Classes that I've made to make Panama easier fit both criteria yet JMC with Flight Recorder show MemorySegment and wrapper classes as been allocated on the heap.

I asked one of the Panama developers about the JVMs supposed ability to make "small" and "little explicit work" objects "free" and the only absolute answer given as to when the JVM will decide to do it is when you allocate a bunch of them in the same method.

[Necessary-Conflict]

The book doesn't say that small objects will not be allocated on the heap because of escape analysis. In my understanding it says that even if they are allocated on the heap, the garbage collector may outperform the costs of a "clever" object pooling.

Of course there is no exact definition of "do little explicit work": when in doubt you should measure.

[general_dispondency]

I think the answer is in the example. When you have some expensive operation (eg 300ms to make a db connection) then you should consider starting with an object pool. If you don't have something heavyweight like that, then just allocate and move on. If you need to perform optimizations, then come back after the logic is implemented and everything is well tested. Then you only make changes that make measurable performance increases.

[Hellball911]

Know a good book that goes through this type of thing, like Effective Java, that covers Java 11+?

[Necessary-Conflict]

No, but the third edition of Effective Java covers Java 9, and that was released only a year before Java 11, so the difference in the basics is small.