[Xion]

Honestly, that doesn't sound like a best practice and more like a convoluted performance hack. It's one thing to use a pre-allocated memory pool for speeding up the creation of objects in native language like C++. Having to the equivalent while working several software layers above that is an example of extremely leaky abstraction.

DOM and Javascript engines still need few more man-centuries of iteration to bring their performance closer to e.g. JVM which doesn't really require hacks like that anymore.

[emehrkay]

Does everything that happens in the JVM happen on a single tread? I think that is the biggest bottleneck when you see slow performing web apps. I think that moving things off to web workers is the natural progression, but browser support...

[craigching]

Not everything, just UI work for AWT/Swing. Pretty much every UI framework that I've worked with over my 20 years of experience is single-threaded, uses an event-based queueing architecture. I'm sure others have a different experience though ;)

[jfim]

You're supposed to do all your graphics-related stuff in a single thread. Swing and JavaFX aren't thread-safe.

[ZoFreX]

> e.g. JVM which doesn't really require hacks like that anymore.

Is this the case?

I used to be pretty in-touch with Java, but haven't been keeping up from the release of 7 onwards. I've picked it up again for game development, and 100% of the performance advice I've found is to use object pooling... but nearly all of that advice is years old, and I have no idea if it still holds true for JRE7 or even JRE6.

It did strike me as something the JVM should be doing for me, so if that has been fixed, that news will be greatly welcomed by the Java game dev community.

[pmahoney]

"Public service announcement: Object pooling is now a serious performance loss for all but the most heavyweight of objects, and even then it is tricky to get right without introducing concurrency bottlenecks."

  -- Brian Goetz in 2005

http://www.ibm.com/developerworks/java/library/j-jtp09275/in...

This article was also written when Java 6 was starting to get escape analysis, which can result in stack allocations in some cases.

I recall taking a course in 2008 or so (Java 6). We were doing a genetic simulation of sorts, and the professor recommended using an object pool to speed things up. I implemented one and observed no measurable difference in my code's performance (these were very small objects used over and over again evolving new organisms). I hooked up a profiler and used that to guide me to some areas that could be improved, and a valuable lesson was learned.

[lucian1900]

Especially the newer generational GCs are very good at letting you create and destroy lots of short-lived objects. Object pools may only be useful for long-lived objects, maybe.

[craigching]

For Java 6 and 7 I would say don't do object pooling, this is probably true for 4 and 5 as well. Creating a new object in Java is very inexpensive and it keeps getting improved. The only argument you might be able to make against creating lots of objects is garbage collection, and for that I'd say profile when you have problems and change only then.