This article reiterates the belief that jvm start-up time is slow is somewhat a myth. When. I measured it years ago, I found jvm start-up time to be roughly equivalent to node.js.<p>What makes start-up time bad in any interpreted language, including Java, python, and JavaScript, is code-loading time. This time is 0(n), where n is the total size of your app, including transitive dependencies. It takes time to load, parse, and validate non-native code. This time far dwarfs any vm start-up time.<p>As an experiment, write a hello world node.js app and time it's execution. Then add an import statement on the aws sdk. Don't actually use it. Just import it! When I last measured it, this caused start-up time to go from 30 Ms to something like 300 Ms. The extra time mostly comes from loading code.<p>For a native app, the binary itself just gets mmapped into memory. Shared library loading is more expensive, but not much, and way less than loading source code or byte code.<p>The tldr is if you want a fast starting non-native app, you have to shrink the transitive dependency closure your app loads to do it's job. This is easy for toy benchmark apps but can be harder for real apps. It also goes against the philosophy of most devs to rely on third party libraries for everything. For instance, If you care about start-up time, it may be worth re implementing that function you'd normally get from guava or apache commons. You can alternatively use a tool like proguard to shrink your dependency closure.