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

TypeDiscoverer is extremely slow (again) #657

Closed
bnordli opened this issue Jun 18, 2015 · 2 comments
Closed

TypeDiscoverer is extremely slow (again) #657

bnordli opened this issue Jun 18, 2015 · 2 comments
Labels

Comments

@bnordli
Copy link
Contributor

bnordli commented Jun 18, 2015

Caching of implemented types was added in #426, but was recently removed (commit 3e787da).

It is imperative that caching of implemented interfaces is kept! Profiling ProCoSys with Bifrost 1.0.0.28 takes 30-50 seconds (!) for each request to Bifrost/Security, with most of the time spent inside RuntimeType.GetInterface.

@einari
Copy link
Contributor

einari commented Jun 18, 2015

Looked at the cache when refactoring this and just concluded - that can't be that slow as to need a caching mechanism. And out it went.. 🎱 What I say about the word assume applies here.. It just makes an Ass out of U & Me.

I'll have a look at it ASAP.

@einari einari added the Core label Jun 18, 2015
@bnordli
Copy link
Contributor Author

bnordli commented Jun 19, 2015

Small update: Most of the seconds spent in Bifrost/Security for us was because of a cache that didn't work properly. But still: Profiling of a small sample useage of the ProCoSys app shows 40% time spent in TypeFinder.FindMultiple, so this is still an important issue.

@einari einari closed this as completed Jun 22, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants