Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Java (http://www.velocityreviews.com/forums/f30-java.html)
-   -   Does object pooling *ever* make sense? (http://www.velocityreviews.com/forums/t390693-does-object-pooling-ever-make-sense.html)

Chris 02-08-2007 12:53 AM

Does object pooling *ever* make sense?
 
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?

Lew 02-08-2007 03:17 AM

Re: Does object pooling *ever* make sense?
 
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

Daniel Pitts 02-08-2007 04:06 AM

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.





Gordon Beaton 02-08-2007 07:50 AM

Re: Does object pooling *ever* make sense?
 
On Wed, 07 Feb 2007 18:53:15 -0600, 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?


A disadvantage to pooling is that it increases the average age of your
objects, resulting in more live objects at any given time, more
objects that live beyond the "nursery", and consequently more work for
the garbage collector.

You also have to manage the object pool.

So in order for pooling to be effective, there has to be a saving
somewhere that outweighs these costs (and possibly others I haven't
mentioned). I don't think the cost depends as much on the *size* of
the object as it depends on the amount of additional *initialization*
that you need to do before you can use it, assuming that you can avoid
that initialization in the pooled case.

/gordon

--
[ don't email me support questions or followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e

Andreas Leitgeb 02-08-2007 08:25 AM

Re: Does object pooling *ever* make sense?
 
Chris <spam_me_not@goaway.com> wrote:
> Does this hold true when your objects are very large, though? What if
> your object contains a byte [] of length 100K? Or 1Mb?


If you can reuse the byte array without resetting it to zeros
(e.g. if the programs logic is such that every element of
the byte-array is overwritten, anyway) then it is possible
that pooling saves some time, but you take the risk that some
(otherwise minor) bug in your program might turn into nightmare
when old (non-zero) garbage in the array might slip through.


Andy Dingley 02-08-2007 10:37 AM

Re: Does object pooling *ever* make sense?
 
On 8 Feb, 00:53, Chris <spam_me_...@goaway.com> wrote:
> I've read recently that object allocation in recent JVMs is so fast that
> it doesn't make sense to create object pools.


Most of my pooled objects are some sort of reference to an external
resource (e.g. a DB connection) that's inherently expensive. I don't
care what the cost of the object itself is, they're pooled to
economise on this external cost and that's not changed by any JVM
improvement.

Given the low cost of Java object creation I find it hard to justify
pooling for objects that are simply entirely Java anyway. What might
cause me to want to pool them? A stateless singleton is justifiable
but anything with state attached to it probably means as much effort
to create the distinct state for each pooled use of the object as it
does to create a whole new object.


Lew 02-08-2007 01:01 PM

Re: Does object pooling *ever* make sense?
 
Chris <spam_me_...@goaway.com> wrote:
>> I've read recently that object allocation in recent JVMs is so fast that
>> it doesn't make sense to create object pools.


Andy Dingley wrote:
> Most of my pooled objects are some sort of reference to an external
> resource (e.g. a DB connection) that's inherently expensive. I don't
> care what the cost of the object itself is, they're pooled to
> economise on this external cost and that's not changed by any JVM
> improvement.
>
> Given the low cost of Java object creation I find it hard to justify
> pooling for objects that are simply entirely Java anyway. What might
> cause me to want to pool them? A stateless singleton is justifiable
> but anything with state attached to it probably means as much effort
> to create the distinct state for each pooled use of the object as it
> does to create a whole new object.


And remember Gordon's points:

Gordon Beaton wrote:
>> A disadvantage to pooling is that it increases the average age of your
>> objects, resulting in more live objects at any given time, more
>> objects that live beyond the "nursery", and consequently more work for
>> the garbage collector.
>>
>> You also have to manage the object pool.


That "more work for the garbage collector" relates to the fact that it's
harder to garbage collect out of the tenured generation than the nursery.
Except for resource gates, it rarely helps to pool.

- Lew

Andy Dingley 02-08-2007 03:30 PM

Re: Does object pooling *ever* make sense?
 
On 8 Feb, 13:01, Lew <l...@nospam.lewscanon.com> wrote:

> Except for resource gates, it rarely helps to pool.


One somewhat perverse use I have found for object pooling is to avoid
memory leakage. In a context of refactoring truly nasty code, a pool
of re-used objects was one way to avoid coders allocating these things
willy-nilly and never disposing of them afterwards at all! Finite
cruft is (marginally) better than inifinite expanding cruft.

....And it's less cruel than my other technique, with the hot clueiron.


Lew 02-09-2007 12:43 AM

Re: Does object pooling *ever* make sense?
 
Andy Dingley wrote:
> One somewhat perverse use I have found for object pooling is to avoid
> memory leakage. In a context of refactoring truly nasty code, a pool
> of re-used objects was one way to avoid coders allocating these things
> willy-nilly and never disposing of them afterwards at all! Finite
> cruft is (marginally) better than inifinite expanding cruft.
>
> ...And it's less cruel than my other technique, with the hot clueiron.


Of course, in Java one does not often have to explicitly "dispose of" an
object. The usual difficulty is making sure to pull all references away from
an object, but there are a huge number of situations where that isn't necessary.

Consider:

public void foo()
{
Bax bax = new Bax(); // assume it does not wrap a resource
// do some stuff with bax
// but do NOT create other references to the object
}

No explicit disposal needed for the new Bax if it is never referenced
somewhere else, e.g., in a long-lived Collection. Once the variable "bax" goes
out of scope in that scenario, the programmer can rest easy.

It is actually a good idiom in Java to "allocat[e] ... things willy-nilly".

- Lew

Joe Seigh 02-09-2007 02:22 AM

Re: Does object pooling *ever* make sense?
 
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?



Not so much that the gc is so much faster than it's not really all that worse
and the effects of tying up a lot of memory in object pools is more problematic.
The copying collector relies on having enough memory so you don't run out
between normal GC cycles. If you are running out of memory and forcing GC
to run more often, you could just use an object pool and use a WeakReference to
point to the object pool. The pool will be reclaimed on every GC cycle more
or less. The only time a pool will exist is when it's active. I'm assuming
weak references don't slow down GC all that much.

--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.


All times are GMT. The time now is 04:28 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.