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

Scheduler setup causes message conventions to be evaluated multiple times #4107

Open
DavidBoike opened this issue Aug 31, 2016 · 2 comments
Open
Milestone

Comments

@DavidBoike
Copy link
Member

When an endpoint starts up, the message conventions are applied to all types.

Then the Scheduler feature comes along and adds system message conventions in its setup:

context.Settings.Get<Conventions>().AddSystemMessagesConventions(t => typeof(ScheduledTask).IsAssignableFrom(t));

If you follow that method, it calls MessagesConventionCache.Reset();

So now that work is out the window, and (for example) the IsCommand delegate will get called twice more for the same message class, once as part of Conventions.IsMessageType and then as part of Conventions.IsCommandType(t).

Surely we could make this more efficient and shave off a good chunk of startup time for users with lots of included assemblies?

(But not a must-have for RC)

@andreasohlund
Copy link
Member

Surely we could make this more efficient and shave off a good chunk of startup time

Do we have any times?

Should we profile the startup to see where we spend the most time currently?

@andreasohlund andreasohlund modified the milestone: Future Oct 6, 2016
@danielmarbach
Copy link
Contributor

danielmarbach commented Oct 21, 2016

I created an endpoint with 6 message assemblies and a total of roughly 130 messages.
image

Right now the convention scanning is almost not relevant in comparison to assembly scanning which takes up over 50 % of the endpoint configuration build time

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants