-
Notifications
You must be signed in to change notification settings - Fork 70
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
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 |
Would it make sense to generate non-generic "Send" methods per each request? I.e. instead of having a single method ValueTask<Pong> Send(Ping request, CancellationToken cancellationToken = default);
ValueTask<WeatherForecasts[]> Send(GetWeatherForecasts request, CancellationToken cancellationToken = default);
etc Obviously, in that case interfaces IMediator/ISender/IPublisher would be generated as well. Don't know if that's bad (apart from being a breaking change). |
We do that already actually, they are generated on the concrete As a general update - I have a local branch that solves this issue in a bit of a temporary way - I still think interceptors are the way to go, but a dictionary-based approach will probably come as part of 3.0 this summer. Perf wasn't as bad as I'd feared (hopefully it stays that way). I essentially generate switch or dictionary based approach depending on the amount of messages and wether or not lifetime is |
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: