Hi,
I've been profiling some (test-)application context starts lately on Spring Framework 5.x and noticed that with one of our medium-larger applications - which I'm unfortunately not able to share - that during startup almost 100K exceptions are being thrown (caused by some Aspects not in our control). The large majority of this is ending up in ClassUtils.getMostSpecificMethod. The majority of cases seems to be caused by checking for the static factory methods on Map.of, Map.ofEntriesetc. with the target class Properties where we already now that they won't exist. (Properties is checked because Spring Data repositories have an inner bean for the named queries, I believe)
I can't imagine this to be super fast or efficient. Could we do anything about that? I'm wondering if it would make sense to exclude static methods here in the first place. Or have some sort of pre-defined list of methods or classes that we know won't find certain things. Or caching the lookups etc.
We haven't been able to upgrade these apps so far to 6.x because the Spring-Security changes are blocking us from a smoother upgrade, but a quick check also revealed that nothing really drastically changed in that regards in the codebase and the risk of checking for methods that are known to not exist still applies. Having that said, there might be a chance that this particular issue for us is reduced with https://github.com/spring-projects/spring-data-commons/commit/712477bf365def70bad92220304a08dd52393b2e but I haven't been able to confirm this just yet.
Anyhow, I'd appreciate if you could take a look if this can be somehow improved.
Cheers, Christoph
Comment From: sdeleuze
@dreis2211 After discussing with @jhoeller, I implemented filtering out both static and final methods, and that indeed reduces the number of invocations of the rest of the logic. Since ClassUtils#getMostSpecificMethod and ClassUtils#isOverridable are frequently invoked, I optimised the implementation as well. If you can, please share the impact on your application.
If you want to do more test about further optimizations, https://github.com/spring-projects/spring-petclinic is using a lot those methods as well, so feel free to use it to share more specific feedback.
The fix will be available in Spring Framework 5.3, 6.0 and 6.1.
Comment From: dreis2211
@sdeleuze Thanks. I won't be able to share anything in the foreseeable future, at least no in-depth analysis. But I'll see if it has any impact once it's live in one of our applications.