6 ms·

C#/Java are almost as fast, but not for immediate execution environments. If you have one off invocations of the code, Go executables will beat the pants off Ja

C#/Java are almost as fast, but not for immediate execution environments. If you have one off invocations of the code, Go executables will beat the pants off Java as you wait for the JVM to fire up and for HotSpot to kick in.

ed25519FUUU 5y ago
Maybe fast in principle but rarely in practice. I’ve never once worked in a Java codebase that started up shorter than 5 or 10 seconds.
throwaway894345 5y ago
I've heard smart people argue convincingly that the JVM doesn't actually take long to fire up, and that this is something of a myth. It may take a bit of time for the JIT to optimize, but that shouldn't impact basic CLI tools (un-JIT-ed code is basically just interpreted code, and that runs quickly enough). I'd be curious to hear from people who have looked into this.
- kaba0 5y ago
  For smallish programs, a recent JVM will start up in 100ms. This is enough to make some CLI tools (like eg. git, with many separate invocations that return almost instantly) slightly bad to use, but longer running CLI tools are perfectly fine with it. There is also Graal to AOT compile classes and that way the startup time is truly negligible. What actually increases JVM startup time is class loading, as it has to do byte code validation and the like for each new class. This is only apparent for largish frameworks though. As for JIT, there is no much point for short-lived programs. Like, most python scripts are run without that and people write prod code in it.
jpavel2 5y ago
I write a variety of CLI tools for my own use in Java. On this low-end Chromebook (Samsung Chromebook 3 with a Celeron N3060 @1.60GHz) I can start the JVM, load the classes for my CLI program, and print a help message, jpavel@penguin:~$ time rcr -h Usage: RCloner <config path> get|put <entry> [args] RCloner <config path> list real 0m0.316s user 0m0.208s sys 0m0.126s in less than 1/3 of a second. And this is with stock openjdk version 1.8.0_302, which doesn't include the startup time improvements of Java 10 & 12. Sure, I wouldn't write utilities meant to be piped one into another, but for standalone CLI tools, the JVM startup time isn't prohibitive at all.
- leodriesch 5y ago
  I think he was talking more about serverless functions, where 300ms longer for answering an HTTP-request would be pretty long.
  - azth 5y ago
    See GraalVM: https://quarkus.io/ https://quarkus.io/

ed25519FUUU 5y ago

Maybe fast in principle but rarely in practice. I’ve never once worked in a Java codebase that started up shorter than 5 or 10 seconds.

throwaway894345 5y ago

I've heard smart people argue convincingly that the JVM doesn't actually take long to fire up, and that this is something of a myth. It may take a bit of time for the JIT to optimize, but that shouldn't impact basic CLI tools (un-JIT-ed code is basically just interpreted code, and that runs quickly enough). I'd be curious to hear from people who have looked into this.

kaba0 5y ago
For smallish programs, a recent JVM will start up in 100ms. This is enough to make some CLI tools (like eg. git, with many separate invocations that return almost instantly) slightly bad to use, but longer running CLI tools are perfectly fine with it. There is also Graal to AOT compile classes and that way the startup time is truly negligible. What actually increases JVM startup time is class loading, as it has to do byte code validation and the like for each new class. This is only apparent for largish frameworks though. As for JIT, there is no much point for short-lived programs. Like, most python scripts are run without that and people write prod code in it.

jpavel2 5y ago

I write a variety of CLI tools for my own use in Java. On this low-end Chromebook (Samsung Chromebook 3 with a Celeron N3060 @1.60GHz) I can start the JVM, load the classes for my CLI program, and print a help message, jpavel@penguin:~$ time rcr -h Usage: RCloner <config path> get|put <entry> [args] RCloner <config path> list real 0m0.316s user 0m0.208s sys 0m0.126s in less than 1/3 of a second. And this is with stock openjdk version 1.8.0_302, which doesn't include the startup time improvements of Java 10 & 12. Sure, I wouldn't write utilities meant to be piped one into another, but for standalone CLI tools, the JVM startup time isn't prohibitive at all.

leodriesch 5y ago
I think he was talking more about serverless functions, where 300ms longer for answering an HTTP-request would be pretty long.
- azth 5y ago
  See GraalVM: https://quarkus.io/ https://quarkus.io/