Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve performance of ReflectionUtils#getUniqueDeclaredMethods [SPR-10197] #14830

Closed
spring-projects-issues opened this issue Jan 21, 2013 · 7 comments
Labels
in: core status: bulk-closed

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Jan 21, 2013

Thusinthan Kajendran opened SPR-10197 and commented

There is a start up performance issue, if I configure beans for an application with JavaConfig (JavaConfing with more than 100 beans). The time to create the beans increases significantly more than when I configured the beans via XML-Based. I have performed a profile on the project and found that the problem lies in the MethdoeRefelctionUtils. getUniqueDeclaredMethods()( This method try to filteries out overrided methods from superclass).

But if I break the JavaConfig down into smaller files (each file 10 beans), than the start will be performed quickly. I'm well aware that it is better to have smaller files, however, it is the algorithm of the method RefelctionUtils.getUniqueDeclaredMethods () badly designed when more than 100 beans......


Affects: 3.1.2

Attachments:

Issue Links:

  • #16501 ReflectionUtils slow down application startup on WebSphere

1 votes, 5 watchers

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 21, 2013

Chris Beams commented

Hi Thusinthan,

I've just attempted to reproduce this issue without any success. Take a look at commit cb8dc73. Try this yourself by building from source, just ensure that you do the following once you've cloned the repository locally:

git checkout 3.2.x
./gradlew :spring-core:cleanTest :spring-core:test -Dtest.single=ReflectionUtilsTests -PtestGroups="performance"

As you can see, I'm testing to ensure that a class with 100 methods is processed by ReflectionUtils#getUniqueDeclaredMethods in under 10 milliseconds. This should be fast enough for any purposes.

Let us know if you can modify this test to reproduce your issue. Alternatively, feel free to submit a reproduction project per the instructions at https://github.com/SpringSource/spring-framework-issues#readme

Thanks!

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 21, 2013

Thusinthan Kajendran commented

Hi,

your are right, your test actually requries only 10 milliseconds for 100 Methods because you have tested the isolated refelctionmethod. The Problem only accurs in combination with SpringBeans. If you configure with JavaConfig, your SpringBeans will take 92 millisecondsds for 100 beans. I also tired my test with 300 Beans and the result is 6248 milliseconds.

Please find my test-case as attachment.

Thanks
Thusinthan

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 21, 2013

Thusinthan Kajendran commented

The UnitTest with sample JavaConfig

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented May 10, 2015

Anders Wallgren commented

Another problem with this method is that it gets called repeatedly for the same class (I suppose that could be considered a problem with the caller, but nonetheless).

This method could really benefit from caching.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented May 10, 2015

Juergen Hoeller commented

Note that, after the initial report of this issue here, #16501 introduced a cache for ReflectionUtils.getDeclaredMethods already which is also being used through getUniqueDeclaredMethods(). Is the extra filtering in getUniqueDeclaredMethods() really so much extra overhead that it's worth some extra caching there?

Juergen

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented May 10, 2015

Anders Wallgren commented

See screenshot from profiling session -- it would appear so. After implementing the cache in my fork of Spring, time to run this test was reduced from 2 minutes to 20 seconds.

@spring-projects-issues spring-projects-issues added status: waiting-for-triage type: enhancement in: core and removed type: enhancement labels Jan 11, 2019
@rstoyanchev rstoyanchev added status: bulk-closed and removed status: waiting-for-triage labels Jan 11, 2019
@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 12, 2019

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core status: bulk-closed
Projects
None yet
Development

No branches or pull requests

2 participants