4 ms·

100 ms is nowhere near what I'd call "negligible" for a process that might only live a second or two! python -c print 'hello' starts up and shuts down an entir

100 ms is nowhere near what I'd call "negligible" for a process that might only live a second or two! python -c print 'hello' starts up and shuts down an entire Python interpreter in less than 50 ms on my machine, whereas the equivalent Java program never takes less than 120 ms. That seems pretty sad for a language that's had at least an order of magnitude more resources thrown at it.

pron 7y ago
> whereas the equivalent Java program never takes less than 120 ms Then you must be using an old version of Java.
- Groxx 7y ago
  Given that hardware varies, and the article was showing 80-90ms floors: 120ms floor seems entirely reasonable to me.
  - pron 7y ago
    The article wasn't using a current Java, either. Current numbers are under 40ms for Hello, World: https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.html https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.ht...
    - ptx 7y ago
      That's certainly good news and the renewed focus on start-up performance is very welcome. I wonder what the numbers look like for small Kotlin programs. (Although I see now that the comparison disabled CDS on Java 8, so the actual improvement is perhaps not as large as it seemed.)
ivan_gammel 7y ago
In one particular case when a process will live for a second or two, it's indeed a visible delay. But it's just one of many scenarios and it's definitely not the top priority one for applying all those engineering resources. When you build a server application, you just don't care about startup time much - in situations where it matters, green-blue deployment will do a better job to reduce downtime (and, anyway, it's not always the platform startup which contributes to the delay before full availability).
Jimmy123456789 7y ago
The JVM is primarily used for backend server processes that run 24/7. Instant startup time is irrelevant in that context and so it was never a design objective. The HotSpot VM is specifically designed and optimized for long running server processes https://www.oracle.com/technetwork/java/whitepaper-135217.html#hotspot https://www.oracle.com/technetwork/java/whitepaper-135217.ht...
- ptx 7y ago
  Are you sure it "was never a design objective"? Clearly the objective was never achieved, but since Java was initially aimed at set-top boxes, tablet-like devices and web browser applets (all interactive client-side applications) it would be strange to design it exclusively for server-side batch processing.
  - Jimmy123456789 7y ago
    ~100 milliseconds startup is good enough for those applications. ~10ms startup is not specified as one if its design goals https://www.oracle.com/technetwork/java/intro-141325.html https://www.oracle.com/technetwork/java/intro-141325.html edit: and as I mentioned above, the HotSpot VM is specifically, explicitly optimized for long running applications.

pron 7y ago

> whereas the equivalent Java program never takes less than 120 ms Then you must be using an old version of Java.

Groxx 7y ago
Given that hardware varies, and the article was showing 80-90ms floors: 120ms floor seems entirely reasonable to me.
- pron 7y ago
  The article wasn't using a current Java, either. Current numbers are under 40ms for Hello, World: https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.html https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.ht...
  - ptx 7y ago
    That's certainly good news and the renewed focus on start-up performance is very welcome. I wonder what the numbers look like for small Kotlin programs. (Although I see now that the comparison disabled CDS on Java 8, so the actual improvement is perhaps not as large as it seemed.)

ivan_gammel 7y ago

In one particular case when a process will live for a second or two, it's indeed a visible delay. But it's just one of many scenarios and it's definitely not the top priority one for applying all those engineering resources. When you build a server application, you just don't care about startup time much - in situations where it matters, green-blue deployment will do a better job to reduce downtime (and, anyway, it's not always the platform startup which contributes to the delay before full availability).

Jimmy123456789 7y ago

The JVM is primarily used for backend server processes that run 24/7. Instant startup time is irrelevant in that context and so it was never a design objective. The HotSpot VM is specifically designed and optimized for long running server processes https://www.oracle.com/technetwork/java/whitepaper-135217.html#hotspot https://www.oracle.com/technetwork/java/whitepaper-135217.ht...

ptx 7y ago
Are you sure it "was never a design objective"? Clearly the objective was never achieved, but since Java was initially aimed at set-top boxes, tablet-like devices and web browser applets (all interactive client-side applications) it would be strange to design it exclusively for server-side batch processing.
- Jimmy123456789 7y ago
  ~100 milliseconds startup is good enough for those applications. ~10ms startup is not specified as one if its design goals https://www.oracle.com/technetwork/java/intro-141325.html https://www.oracle.com/technetwork/java/intro-141325.html edit: and as I mentioned above, the HotSpot VM is specifically, explicitly optimized for long running applications.