martinothamar / Mediator

A high performance implementation of Mediator pattern in .NET using source generators.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Improve codegen for large projects

martinothamar opened this issue · comments

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:

  • Add overloads for the Send methods that will allow requests without responses to be generic arguments. This is a small improvement for i.e. struct cases where we can avoid boxing. ValueTask<Unit> Send<TRequest>(TRequest request, CancellationToken cancellationToken = default) where TRequest : IRequest;
  • Generate IDs per request that can be mapped to linear array access so that we have close to zero overhead handler lookup. This will require request types to be partial. Not sure if this will become a breaking change or if we can keep it optional and fallback to slower message handling. This is a bigger change but will drastically improve the performance for larger projects

This will require request types to be partial. Not sure if this will become a breaking change or if we can keep it optional and fallback to slower message handling.

I prototyped around that a bit:

  • use static virtual interface, with default value -1
  • use custom attributes annotating the request types which the source generates the override static interface impl with the proper Id
  • check if Id is -1, then use existing fallback code, otherwise linear access array code.

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