No.
Or only very rarely. Only if you have an object that is particularly costly to create, e.g. a state machine for a parsing or cryptographic engine.
With Java your PC can create and garbage collect a couple of hundred million objects per second. It's slower to pool them than to create new ones.
> Or only very rarely. Only if you have an object that is particularly
> costly to create, e.g. a state machine for a parsing or
> cryptographic engine
It is quite interesting though. I built a parser recently, and pooled the state-machines. However, I did all allocation for buffers (byte[]) on demand.
Performance wasn't great - so I created an allocator interface - and put my HeapAllocator head-to-head with a PooledAllocator.
Bang: 35% performance improvement with pooling.
One situation where I have used pooled objects is buffers in a web server. I would construct a web page into a byte[], write it, and return the byte[] into a pool.
100 hits/s at 4 kB/page = 400 kB of garbage per second. Which would have led to pretty frequent garbage collection if I hadn't pooled.
I wonder how well your average JSP engine handles that...
> I wonder how well your average JSP engine handles that...
Pretty darn well, as it happens :o)
Tomcat does hardly any allocation per request.
Nearly all of the internal tomcat classes can be "disposed" or "recycled".
It increases the code complexity quite a bit (you dont want to be leaking those objects!!) - but as I found out myself - is ultimately worth it.
Its also very useful for helping in a centralised dos attack handling strategy.