Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> for short lived programs, it seems reasonable to include the startup time

but then one can say, if the whole problem is so trivial that startup time is a significant chunk of the execution then is it really a problem worth optimising in the first place? The only situation where it would matter is if you are putting this in a tight loop on the command line or something like that (which is a thing, but its a reasonably small thing).



There are actually important cases where the JVM startup time is a huge problem. For example, my team chose Go instead of Java for a microservice solution because, among others, the startup time of a microservice after a scaling event or crash matters a lot for user perception. The difference between a 100ms startup time and a 500ms startup time (or more) is often the difference between a system that seems to 'just work' and a system that seems to 'constantly stutter'.


When my deployments are incremental I barely care about startup time. Even if a service takes ten seconds to come up healthy (which is mostly pubsub and polling backends, not classloading) we can upgrade the entire production tier 1% at a time in under twenty minutes, which is about as fast as I’d be comfortable going with automatic plus manual monitoring. And I don’t really expect sub-second response times and image load times from cluster schedulers like YARN or Apache Mesos or EC2.

I admit that Java is doing a lot of redundant bytecode verification and typechecking work at classload time, but nothing would really change if it were free. I certainly don’t want to give up plugins and AspectJ the way Go does.


I am by no means a devops expert, but it seems strange that 400ms would matter all that much, when the vm itself takes similar amounts of time for a new instance.

Either your application crashes way too much, or the scaling is not implemented properly.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: