4 ms·
My experience leads me to the exact opposite conclusions. For example, your code cache is either big enough or it's not. It's a pretty binary situation and a si
by PathOfEclipse 4y ago
My experience leads me to the exact opposite conclusions. For example, your code cache is either big enough or it's not. It's a pretty binary situation and a simple checkbox to ensure your app didn't run out of space. To quote from https://stackoverflow.com/questions/7513185/what-are-reservedcodecachesize-and-initialcodecachesize https://stackoverflow.com/questions/7513185/what-are-reserve...:
"Normally you'd not change this value. I think the default values are quite good balanced because this problems occur on very rare occasions only (in my experince)."
Similarly, your organization tends to run the version of Java that the whole company supports. I have never worked anywhere where someone was allowed to use a different version than the rest of the company for performance reasons.
In contrast, the advice to write low-level code for predictable, high performance has been virtually timeless and generally applicable across languages.
- jeffbee 4y agoI'm not suggesting that devs should just wildcat a newer JDK, but surveys indicate that significant population of organizations are still on 8 or even 7. If that's your org, this is probably performance left on the table. As for the code caches, you're right that it's a binary outcome, but the signals are subtle and if you aren't looking at the right stats a non-expert without a good calibrated gut feeling for how good the performance should be might just conclude that the app was written poorly, or Java just sucks, or whatever.