5 ms·
Java is both compiled (first to bytecode, then to machine code by the JIT) and fast (once JIT compiled).
by haimez 1y ago
Java is both compiled (first to bytecode, then to machine code by the JIT) and fast (once JIT compiled).
- Raidion 1y agoJava is "fast" but not fast. Most of the time if performance is a true concern, you are not writing code in Java.
- frollogaston 1y agoI have yet to run a Java program that I haven't had to later kill due to RAM exhaustion. I don't know why. Yeah an Integer takes 160 bits and that's without the JVM overhead, but still. Somehow it feels like Java uses even more memory than Python. Logically you'd point the finger at whoever wrote the software rather than the language/runtime itself, but somehow it's always Java. It's like the Prius of languages. Ok, just glanced at my corp workstation and some Java build analysis server is using 25GB RES, 50GB VIRT when I have no builds going. The hell is it doing.
- AlotOfReading 1y agoMore of a historical footnote than a serious example, but you've never had to kill the Java applications running on your SIM card (or eSIM).
- frollogaston 1y agoI don't know about that, my flip phone used to crash quite often. And it displayed a lot of Java logos.
- AlotOfReading 1y agoDifferent processor and JVM. My understanding is that early versions of the Java card runtime didn't even support garbage collection. It was a very different environment to program, even if the language was "Java".
- lmm 1y ago> Ok, just glanced at my corp workstation and some Java build analysis server is using 25GB RES, 50GB VIRT when I have no builds going. The hell is it doing. Allocating a heap of the size it was configured to use, probably.
- frollogaston 1y agoThat's a max size, not a preset allocation. The process normally starts out using 1GB.
- lmm 1y agoSure, but if it's had to use a lot at some point in the past it usually holds onto it.
- frollogaston 1y agoThat would explain it, but also, that's super broken
- lmm 1y agoIt's not a big issue for a server deployment where if you got that memory from the OS and didn't get killed, there's probably nothing else running on the box and you might as well keep it for the next traffic spike. But yeah not ideal on the desktop/workstation.
- noelwelsh 1y agoNothing broken about it. It's optimized for a particular situation, that situation being a long running process on a server. This is where the JVM typically runs. If you don't want that behaviour there are a myriad of GC options, which could be better documented but are not that hard to find.
- frollogaston 1y agoI'm not the one who wrote it though, and it's software designed to run on a workstation.
- cherrycherry98 1y agoGC usually only runs when the process wants to allocate an object but there's no space left on the heap. It's entirely possible that it did a bunch of work previously which created a bunch of garbage now waiting to be cleaned up. See the G1PeriodicGCInterval flag to enable idle collections (assuming G1). Java is also fairly greedy with memory by default. It likes to grow the heap and then hold onto that memory unless 70% of the heap is free after a collection. The ratios used to grow and shrink the heap can be tuned with MinHeapFreeRatio and MaxHeapFreeRatio.
- _w1tm 1y agoWhy do Java developers still have to tune stuff like that?
- frollogaston 1y agoBefore I even went on my rant, I was guessing there's just some confusing default like this but there's also some historical reason why it's like that.
- deleted 1y ago[deleted]
- adgjlsfhk1 1y agodon't slander the Prius! it's an incredibly efficient and robust machine. Java is a Chevy Colerado. surprisingly common for how unreliable it is
- frollogaston 1y agoThat's what I mean, surely the Prius can reach 100mph, but you rarely see it go past 55. Usually in the fast lane. It's a paradox.
- lmm 1y agoJava is fast for long-running server processes. Even HFT shops competing for milliseconds use it. But yeah every user-facing interactive Java application manages to feel clunky.
- symbolicAGI 1y agoLearned from an NYC exchange 10 years ago that Java can be written so as to not use garbage collection. Fast and no pause for GC. 1. Resource and reuse objects that otherwise are garbage collected. Use `new` sparingly. 2. Avoid Java idioms that create garbage, e.g. for (String s : strings) {...}, substitute with (int i = 0, strings_len = strings.length(), i < strings_len) { String s = strings[i]; ...}
- jandrewrogers 1y agoIt depends on what you are using it for, “fast” is relative. Java can be fast for applications where performance and scalability are not a primary features. If performance and scalability are core objectives, even performance-engineered Java isn’t really competitive with a systems language. You can bend Java to make it perform better than most people believe, especially today, but the gap is still pretty large in practice. I wrote performance-engineered Java for years. Even getting it to within 2x worse than performance-engineered C++ took heroic efforts and ugly Java code.