▲ | deanCommie 10 hours ago | |||||||||||||
The other problem with it is that there are other variables involved besides pure speed, which is CONSISTENCY of speed. Folks are always surprised to see just how fast Java is able to perform on benchmarks - it has a reputation as such a slow language then how come it's able to execute almost as fast as C++? But Java's problem isn't execution performance. It's: * Startup performance. It takes time to instantiate the JVM. That matters for some, not for others. * Consistent performance. This is the nature of Garbage Collection. It can surprise you when it executes you and drop a performance blip when you least expect it. Most developers who think they need the fastest performance actually need CONSISTENT performance more than the fastest. | ||||||||||||||
▲ | PaulHoule 10 hours ago | parent | next [-] | |||||||||||||
I even see some video games (say Dome Keeper) that periodically go out to lunch even on a top of the line gaming PC and understand that kind of game is often written in C# which has a garbage collector. Thing is I remember playing games on the much weaker PS Vita that were written in C# but I never remember pausing like that. VR games are now the frontier of gaming (in terms of the industry outdoing itself) and there you're approaching hard real time requirements because it is so awful to get seasick. I appreciate it. | ||||||||||||||
| ||||||||||||||
▲ | vitus 7 hours ago | parent | prev [-] | |||||||||||||
> * Consistent performance. This is the nature of Garbage Collection. It can surprise you when it executes you and drop a performance blip when you least expect it. This has been getting much better in Java in recent years. Shenandoah has been the default since Java 15, and we've been seeing further improvements since then. > Processing thread stacks concurrently gives us reliable sub-millisecond pauses in JDK 17. https://developers.redhat.com/articles/2021/09/16/shenandoah... |