-
Notifications
You must be signed in to change notification settings - Fork 67
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 codegen for large projects #48
Labels
enhancement
New feature or request
Milestone
Comments
I prototyped around that a bit:
This will then be backwards compatible. |
Thanks again. Sounds like a good solution! This issue is on the top of my list after 2.0 is fully release, which should be in the next few days hopefully |
9 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As per discussion from #7 (comment), performance for large projects is pretty bad for cases where we don't have a statically known type as method parameter (i.e.
ValueTask<TResponse> Send<TResponse>(IRequest<TResponse> request, CancellationToken cancellationToken = default);
). There are some easier wins to be had, but none that preserves the performance advantage that are seen on smaller projects.I've created the Mediator.Benchmarks.Large project which tracks performance for the above mentioned overload when there are 1000 requests in the assembly.
To not delay 2.0 much further I'm going to complete this release first, then start the work on improving the perf situation:
ValueTask<Unit> Send<TRequest>(TRequest request, CancellationToken cancellationToken = default) where TRequest : IRequest;
The text was updated successfully, but these errors were encountered: