5 ms·

Might be quick when running but the jvm startup time is a pain. By the time the java solution starts up, my c based solution has already finished.

tlammens 11y ago
Startup time in a server is a non-issue... Those processes keep running the whole time.
- javaispoo 11y ago
  Yeah, and memory is infinite, and all disks are free, and the computing fairies make all the processors super fast. But back in the real world, startup time is a valid concern.
  - sarnowski 11y ago
    Don't know your "real" world. In my real world, the AWS instance takes several minutes to come up - I can spare some milliseconds on thr JVM startup.
    - vidarh 11y ago
      In my real world the containers we spin up come up in seconds, but container restart is far more rare than restarting services.
      - thescrewdriver 11y ago
        If the time to restart your process or host affects the overall operation and performance of your service you're doing it wrong.
        astrange 11y ago
        That just means you expect restarting to be slow and have excluded it from your system design. There is no problem with restarting nginx to update its config once a second, and it's even encouraged that you do so. Besides, crash-only software recovery is really the only morally sound development technique.
        vidarh 11y ago
        If your services consistently restart quickly, it gives you the freedom to design things differently. E.g. doing a rolling update across a large number of instances by restarting a service at a time can become a quick enough process to be viable in instances where you'd otherwise need lots of excess capacity to be able to cycle larger proportions of instances at the same time. Making full rolling updates "cheaper" both in time and resources also translates to making rapid updates a safer choice (e.g. if I can roll back a broken release in 5 minutes, it's far safer to push out a new release than if a rollback takes hours).
  - Twirrim 11y ago
    What are you doing that you frequently starts / shuts down an application to the order where 70ms is a problem?
    - eterm 11y ago
      Not just frequently starting/stopping applications but a persistence engine at that.
  - astrodust 11y ago
    How many reboots per second are you having to endure? Maybe you should make your server process crash less often.
sarnowski 11y ago
http://blog.ndk.io/2014/02/11/jvm-slow-startup.html http://blog.ndk.io/2014/02/11/jvm-slow-startup.html 40ms sounds okay for me, even for most command line tools. Oh and I most probably don't get a segmentation fault ;-)
- pjc50 11y ago
  That rather proves the opposite: 6s Clojure startup time, for reasons that aren't obvious enough to be included in that blog post.
  - sarnowski 11y ago
    But its neither a Java nor JVM problem.
- juliangregorian 11y ago
  Sure wish my JVM started in 40ms. Here's ruby: $ time ruby -e "puts 'hello world'" > hello world > > real 0m0.076s > user 0m0.029s > sys 0m0.017s And here's jruby: $ time ruby -e "puts 'hello world'" > hello world > > real 0m1.161s > user 0m2.050s > sys 0m0.093s
  - ssmoot 11y ago
    Your JVM does. jruby.jar is megabytes of reimplementation and mapping of the Ruby stdlib onto the JVM. Plus in this example, loading a Ruby parser and interpreter. Here's executing an assembly (über-jar) I wrote in Scala: → time scripts/couch Please provide a basePath and a valid command. ("backup", "restore", "truncate", "migrate" or "migrate-all") real 0m0.375s user 0m0.415s sys 0m0.073s That's basically just `java -jar couch-utils.jar`. A few hundred ms on my 1.2GHz MacBook. And this includes a bunch of Akka Actors.

tlammens 11y ago

Startup time in a server is a non-issue... Those processes keep running the whole time.

javaispoo 11y ago
Yeah, and memory is infinite, and all disks are free, and the computing fairies make all the processors super fast. But back in the real world, startup time is a valid concern.
- sarnowski 11y ago
  Don't know your "real" world. In my real world, the AWS instance takes several minutes to come up - I can spare some milliseconds on thr JVM startup.
  - vidarh 11y ago
    In my real world the containers we spin up come up in seconds, but container restart is far more rare than restarting services.
    - thescrewdriver 11y ago
      If the time to restart your process or host affects the overall operation and performance of your service you're doing it wrong.
      - astrange 11y ago
        That just means you expect restarting to be slow and have excluded it from your system design. There is no problem with restarting nginx to update its config once a second, and it's even encouraged that you do so. Besides, crash-only software recovery is really the only morally sound development technique.
      - vidarh 11y ago
        If your services consistently restart quickly, it gives you the freedom to design things differently. E.g. doing a rolling update across a large number of instances by restarting a service at a time can become a quick enough process to be viable in instances where you'd otherwise need lots of excess capacity to be able to cycle larger proportions of instances at the same time. Making full rolling updates "cheaper" both in time and resources also translates to making rapid updates a safer choice (e.g. if I can roll back a broken release in 5 minutes, it's far safer to push out a new release than if a rollback takes hours).
- Twirrim 11y ago
  What are you doing that you frequently starts / shuts down an application to the order where 70ms is a problem?
  - eterm 11y ago
    Not just frequently starting/stopping applications but a persistence engine at that.
- astrodust 11y ago
  How many reboots per second are you having to endure? Maybe you should make your server process crash less often.

sarnowski 11y ago

http://blog.ndk.io/2014/02/11/jvm-slow-startup.html http://blog.ndk.io/2014/02/11/jvm-slow-startup.html 40ms sounds okay for me, even for most command line tools. Oh and I most probably don't get a segmentation fault ;-)

pjc50 11y ago
That rather proves the opposite: 6s Clojure startup time, for reasons that aren't obvious enough to be included in that blog post.
- sarnowski 11y ago
  But its neither a Java nor JVM problem.
juliangregorian 11y ago
Sure wish my JVM started in 40ms. Here's ruby: $ time ruby -e "puts 'hello world'" > hello world > > real 0m0.076s > user 0m0.029s > sys 0m0.017s And here's jruby: $ time ruby -e "puts 'hello world'" > hello world > > real 0m1.161s > user 0m2.050s > sys 0m0.093s
- ssmoot 11y ago
  Your JVM does. jruby.jar is megabytes of reimplementation and mapping of the Ruby stdlib onto the JVM. Plus in this example, loading a Ruby parser and interpreter. Here's executing an assembly (über-jar) I wrote in Scala: → time scripts/couch Please provide a basePath and a valid command. ("backup", "restore", "truncate", "migrate" or "migrate-all") real 0m0.375s user 0m0.415s sys 0m0.073s That's basically just `java -jar couch-utils.jar`. A few hundred ms on my 1.2GHz MacBook. And this includes a bunch of Akka Actors.