5 Coding Hacks to Reduce GC Overhead

Re:5 Coding Hacks to Reduce GC Overhead by stevoski on Thursday July 18, 2013 @11:10AM (#6064136)

This article is way inaccurate. It recommends approaches that were maybe important in 1997. It also breaks the "profile before optimising" rule.

Currently the Java GC works splendidly with lots of short-lived, small immutable classes. Using this approach can be far better for performance than worrying about telling the ArrayList constructor how many elements the list will probably have.

[ Parent | on HN ]

Re:5 Coding Hacks to Reduce GC Overhead by saurik on Thursday July 18, 2013 @12:47PM (#6064794)

While VMs like Sun's may be using techniques like escape analysis, I seriously doubt that Dalvik does (it seems like dx might, but that's going to be of limited value at compile time, and it isn't clear how it uses the information): a lot of people these days coding in Java are doing so for Android, where the garbage collector is a serious problem, sufficiently so that all garbage collections are logged to the system log (so as a developer you don't even need to go to much work to profile it as an issue: you just see the pain in your console and then likely seem out this article).

[ Parent | on HN ]

Re:5 Coding Hacks to Reduce GC Overhead by SpikeGronim on Thursday July 18, 2013 @12:24PM (#6064643)

Absolutely. Step 0 of this article should have been "profile your GC and establish that it is a problem."

[ Parent | on HN ]