[curun1r]

I don't know if it's still a problem with Spring, but at a previous job about 8 years ago I was able to cut our application's start time from about 80 seconds to ~12 by writing a custom implementation of the logic that Spring used to find bridge methods to determine the proper annotations. We profiled the startup and found that over 80% of the time was being spent in reflection to resolve those bridge methods and that could be done significantly faster by using asm to load the classfile bytes and resolve the bridge method by looking directly at the invokevirtual call. Spring avoided this approach because it could fail in situations where the SecurityManager prevented filesystem access.

I don't know if that's still the case, but it always bugged me that Spring would slow down the >99% case by so much just to accommodate the <1% case.

[jacques_chester]

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/

[semi-extrinsic]

> 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.

[jacques_chester]

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.