Hacker News new | past | comments | ask | show | jobs | submit login

Dave Syer looked at this topic recently[0]. Most of the time spent in loading isn't due to reflection or annotation processing: it's proportional to the number of classes loaded.

That said, Spring is fairly enthusiastic about pulling stuff. As he says:

> Since more beans mean more features, you are paying at startup for actual functionality, so in some ways it should be an acceptable cost. On the other hand, there might be features that you end up never using, or don’t use until later and you would be willing to defer the cost. Spring doesn’t allow you to do that easily. It has some features that might defer the cost of creating beans, but that might not even help if the bean definitions still have to be created and most of the cost is actually to do with loading and parsing classes.

I imagine that they'll keep poking at it, especially since they're working on Spring Cloud Function[1], where cold starts for single invocations are common.

[0] https://github.com/dsyer/spring-boot-startup-bench/tree/mast...

[1] http://cloud.spring.io/spring-cloud-function/




> most of the cost is actually to do with loading and parsing classes

It boggles my mind that loading and parsing even a few thousand classes is something that a human can perceive as "dog slow" when carried out by a quad-core 1.2 GHz CPU.


My understanding is that it's I/O bound, that the JVM more or less fetches each class from the JAR file or disk individually.

I am not sure if that's an implementation decision or whether it's imposed by the JVM specification. At some point I want to tinker with OpenJ9 to find out.




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

Search: