
A Well Known but Forgotten Trick: Object Pooling - hepha1979
http://highscalability.com/blog/2015/7/29/a-well-known-but-forgotten-trick-object-pooling.html
======
twic
Object pooling was very common in Java last century. Today, it survives only
for the most heavyweight objects: threads, database connections, web browsers,
that sort of thing.

What killed it off was generational collection. Compacting generational
collectors make allocation very cheap, and they make maintenance of short-
lived objects very cheap. As a result, it's reliably cheaper to allocate an
object and throw it away than it is to attempt to reuse it.

So it's surprising and interesting to read that the author of this article
clearly thinks that there are still benefits to object pooling. Since Alex
Petrov is a very sharp guy, i have to take him at his word. But it's a shame
he didn't include benchmarks to compare it to idiomatic use of a modern GC.

~~~
vitalyd
It's very much alive in the java low latency space where even young GCs are a
problem. Allocations of temps/short lived objects also wash your cpu caches,
and generally there are other reasons to avoid any GC in this space.

~~~
ketralnis
> java low latency space where even young GCs are a problem ... there are
> other reasons to avoid any GC in this space

I'm no Java hater, but that sounds like the wrong place to use Java in the
first place

~~~
vitalyd
It has its pros/cons but you'd be surprised (perhaps) at the throughput and
latency you can get if you're mindful of things to avoid.

~~~
kctess5
Which is, IMO, a part of the reason why Java isn't great for that. A serious
pro can make it go like a race horse, but beginners and even long time users
may fall into traps. If a language has less things to be mindful of, it's
users may be less mindful with fewer dire consequences.

Of course, this totally depends on who might be touching the codebase...

~~~
EdSharkey
I think this is more an article about garbage collecting vm's, namely the JVM,
than it is about java, the language.

The JVM is being used in Mt. Everest-sized workloads. Object pooling is a
useful tool when architecting something huge and performance sensitive.

------
tbirdz
Object pools are certainly a very useful technique, but can they really be
considered a "forgotten trick"? This kind of pooling is pretty basic CS
knowledge, and thus is a very popular technique in many applications,
libraries, etc. I would have assumed most people working with a need for scale
in a GC language like Java would be familiar with this technique (dare I call
it a "design pattern")

Perhaps I am wrong and the technique is less familiar than I had thought?.

~~~
ajuc
It's everywhere in java ee. Still I guess people writing fronted may have
never heard of it (except thread pools?).

~~~
ericflo
People writing frontend learn how to pool objects very quickly in both iOS and
Android for list/collection view cells.

------
macrael
Another example of this: table views in Cocoa. Enough cells to fill the screen
are allocated and then just updated instead of re-created as cells scroll off
screen.

------
nemesisrobot
IIRC, LMAX Disruptor[0] uses the same concept with its ring buffer to avoid
GC-related slowdown.

[0]: [https://github.com/LMAX-Exchange/disruptor](https://github.com/LMAX-
Exchange/disruptor)

~~~
vitalyd
While it does avoid GC, it's mostly a faster way to share data between threads
than the builtin concurrent collections.

~~~
nemesisrobot
Yep, that's what Disruptor is for. Here's a blog post by one of the devs
giving more details about the ring buffer where she specifically mentions that
objects are pooled to avoid the GC
[http://mechanitis.blogspot.com/2011/06/dissecting-
disruptor-...](http://mechanitis.blogspot.com/2011/06/dissecting-disruptor-
whats-so-special.html)

------
lucb1e
If this is a forgotten trick, then why did we learn about this in school? It
was in Java classes though, never heard of it being needed elsewhere, but the
concept is generally applicable.

~~~
rch
IIRC it's discussed in Bulka & Mayhew - Efficient C++: performance programming
techniques

[http://dl.acm.org/citation.cfm?id=320041](http://dl.acm.org/citation.cfm?id=320041)

------
newobj
Pooling and in-place reuse are two different things, to be sure.

This was a fun thing I remember writing:
[https://github.com/newobj/ffwd/blob/master/Src/Core/Std/Allo...](https://github.com/newobj/ffwd/blob/master/Src/Core/Std/Allocator.h)
When returned to the pool, each object used the first 4 bytes of itself to
point to the next free one in a list, so there was no additional overhead.

------
amelius
I can see a security nightmare lurking around the corner.

~~~
pcwalton
I don't know why this was downvoted. This vulnerability in Jetty was the
result of sharing a buffer between requests:
[http://blog.gdssecurity.com/labs/2015/2/25/jetleak-
vulnerabi...](http://blog.gdssecurity.com/labs/2015/2/25/jetleak-
vulnerability-remote-leakage-of-shared-buffers-in-je.html)

------
zwerdlds
It's been a while, but this was a common technique for agent based modeling in
MASON back in the day.

Having tens of thousands of agents constantly being garbage invalidated was
the use case.

------
davelnewton
If it's well-known it's not forgotten.

(Not really sure it's forgotten, either; it's used regularly for heavy
objects, or when speed is _absolutely_ critical.)

------
LCDninja
Object pooling is essential for performance in Unity 3D if you're dealing with
large amounts of game objects.

------
shanemhansen
Object pooling is alive and well. Take a look at go's sync.Pool.

------
wangii
question:

which is cheaper, stack object allocation/creation or object pooling, in
languages like C/C++/Rust?

~~~
tbirdz
The stack is cheaper, but it is a limited size. If you need more objects than
would fit on the stack, pooling might be a better choice.

~~~
joelwilliamson
The stack doesn't have to be limited. On a 64-bit system, you can give each
thread a couple of terabytes of stack space with no problem.

~~~
aidenn0
For amd64 on linux you only have 128TB; with green threads I regularly use a
lot more than 64 threads.

