Re: Does object pooling *ever* make sense?
On Feb 7, 7:17 pm, Lew <l...@nospam.lewscanon.com> wrote:
Chris wrote:
I've read recently that object allocation in recent JVMs is so fast that
it doesn't make sense to create object pools. Just create a new object
when you need it and let the garbage collector do the work.
Does this hold true when your objects are very large, though? What if
your object contains a byte [] of length 100K? Or 1Mb?
What's the breakeven point beyond which it makes sense to reuse objects?
As I understand, the memory allocation procedure in the JVM is to add some
size n to a pointer p and call that region the new object. I don't think there
is anything much faster than that. It takes the same amount of time to add 10M
to p as to add 10. (<=1 cycle?)
The time spent is zeroing the memory, I'd guess, but you'd have to do that
with an object pool, too.
I surmise that there is no breakeven point.
- Lew
I'd suggest running a few tests to find out.
The best suggestion I can make is to wrap all your calls to "new" in a
method somewhere, so that if you decide you need to pool, you can.
Generally, its bad engineering to worry about speed before it becomes
a problem. The first priority is clarity. Next to functionality of
course.
If you find that there is a speed (or memory) issue, THEN you run a
profiler (don't ever "guess" or speculate on what the problem is,
you'll most likely be wrong, no matter how good you are)
The profiler will tell you what you need to optimize.
Hope this helps.