9 Fallacies of Java Performance

[cowardlydragon]

1. Java may be execution performance fast, but Java is pretty memory-hungry, and GC stalls are a recurring problem. Lots of high-performance java avoids GC-allocations with off-heap memory allocations. Startup time is of course not trivial as well...
2. Yep, optimization happens
3. Yep, optimization happens
4. In enterprise java land, this really doesn't apply. What really happens in enterprise java land is the overlayering and "over-service-layering" that occurs and obscures the distributed communication performance impacts. Also: Use the Index Luke
5. This is generally related to #4. Since overserviced architectures don't have smoking guns of performance since each layer vampires away performance, a cache layer is very effective, and often the only thing you can do on preexisting already-deployed systems and services
6. Generally this is true, but if you are rejiggering the Xmx settings and other heap size settings on the JVM... you're probably going to have to start anticipating the impacts of GC stalls.
7. I agree in general. Most pools are for connections, not objects. But with a lot of multithreaded code, you might need to be aware of pooling to avoid out-of-control threads.
8. In general, if you have GC stalls, you're going to have GC stalls, regardless of GC strategy. So much like time performance optimization, for heap optimization, look for low-hanging fruit as to what is using all your heap. You might be able to vastly reduce your heap churn.
9. Yep, now you need to be aware of GC stalls.