8000 Speed up getBean() for singletons with complex dependencies? · Issue #409 · framework-one/fw1 · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Speed up getBean() for singletons with complex dependencies? #409

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.

Sign up for GitHub

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

Jump to bottom
Closed
seancorfield opened this issue Dec 16, 2015 · 3 comments
Closed

Speed up getBean() for singletons with complex dependencies? #409

seancorfield opened this issue Dec 16, 2015 · 3 comments
Assignees
@seancorfield
Labels
enhancement
Milestone
4.0

Comments

@seancorfield
Copy link
Member

Can we safely add a top-level cache for singletons so that explicit calls to getBean() are very fast?
@seancorfield seancorfield self-assigned this Dec 16, 2015
@seancorfield seancorfield added this to the 4.0 milestone Dec 16, 2015
seancorfield added a commit that referenced this issue Dec 16, 2015
@seancorfield
Tentative top-level singleton caching #409
37d10a3
seancorfield added a commit that referenced this issue Dec 16, 2015
@seancorfield
Tackle dependency caching too #409
891e6ea
seancorfield added a commit that referenced this issue Dec 16, 2015
@seancorfield
Minor tweak for #409
b853811 
Ensure we don't overwrite any cached dependencies
seancorfield added a commit that referenced this issue Dec 16, 2015
@seancorfield
Ensure caching doesn't mess with construct args #409
db17e5b
@seancorfield
Copy link
Member Author

This provides a substantial speedup in the pathological case and doesn't appear to break anything so I'm inclined to close this out as "fixed" but I want to get feedback from @cameroncf first.

@cameroncf
Copy link
Contributor

I ran this on my stand alone test code and saw a pretty healthy jump in performance. This is definitely a big improvement - about 25-30x, which agrees with the numbers you saw.

I've also tried the updates DI/1 file out in a full blown "pathological" application that had problems around getBean() and there is a performance boost there too. Not quite as large since DI/1 is only a part of the larger app, but it seems to have sped things up overall by about 30% overall in that app.

I suspect others will experience some performance gain form these changes as well, though it will probably be far less dramatic than my somewhat extreme edge case.

I plan to do a lot of work in the app today with getBean() and removing the pathological nature of the code so I'll report back if I find any other negative side effects of this change. I looked at the code you changed though and it looks pretty safe.

@seancorfield
Copy link
Member Author

Thanks for your feedback @cameroncf -- I'll consider this "done" now! Feel free to post back with your findings tho' as it will be useful information for others (and for the 4.0 release notes!).

@seancorfield seancorfield mentioned this issue Dec 10, 2016
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@seancorfield seancorfield

Labels
enhancement
Projects
None yet
Milestone
4.0
Development

No branches or pull requests
2 participants
@seancorfield @cameroncf
0