How slow is MediatR really?

Hello everybody I'm Nick and in this video I will investigate a claim around the library MediatR and how it can affect your application's performance. This video will also introduce you to performance measuring and memory profiling techniques.

Don't forget to comment, like and subscribe :)

Social Media:

#csharp #dotnet #mediatr

[nickchapsas]

Something that I forgot to mention in the video is that, when you add some IO into the mix (database call, api call etc) the difference will get even smaller because the IO will loadbalance it out of the equation.

[jradplowman]

Nick your videos are pure gold. Your presentation and pacing are perfect. Also your approach is so easy to follow! Thanks again for the great content.

[JesseTemple]

We use MediatR in a production environment with good results, but I never got this far down into the weeds about it. This was a very interesting video, thanks!

[ThiagoFer]

I feel like most developers are always seeking the best practices overall and forget to ask what is the best for their situation, which can lead to hard to handle cannon that is used to kill an ant.
It all comes to the problem you need to solve. In my company, we have some smaller applications that use MediatR. We never faced performance issues and my team just like to work with this library, because how the code feels cleaner and outweighs the performance "cost". It works for us in that situation and we are happy with maintening it.

[RENAUDADAM]

Hey Nick, awesome to see a video on this content! As always really well done :). I agree that the benefits of MediatR generally speaking outweigh the performance cost. That said, the memory allocation issue related to the service can almost be completely removed by making the service a singleton, if your use case permits. It would be interesting if MediatR also allowed you to register handlers as singletons.

[pablocom]

Super interesting how it affects in terms of memory allocation, thanks again Nick!

[bormokov]

very good evidences bro, thanks for best clarifications

[thomas]

Thank you for putting so much effort into it. I learned a lot from this video.
I'm gonna stick with Mediatr :-)

[diadetediotedio]

I think many people have a hard time understanding that not everything is about raw performance, if that were the case we would only write with low-level languages like ASM, C or Rust. We use high-level languages because we want to increase the readability of our code as much as possible and reduce human error at the maximum possible rate, the objective with this is to make the product something agile to develop and with a low error rate. If you worry too much about performance trying to cut costs, you will end up impacting your bottom line and making those lower costs less valuable in and of themselves.

[kjbetz]

Great thorough tests, explanations, and video! Thank you!

[josepvg]

Thanks for a great video. I think when you add some IO bound code to the sample this overhead becomes minimum and I also think in 99% of cases doing such low level optimization as using services instead of the Mediatr makes the code more complex. It is then much more difficult to maintain, bugfix and refactor for high level optimization

[kblyr]

MassTransit also has an implementation of the Mediator Pattern, I have a feeling that there will be a huge difference in terms of performance, but I'm too lazy to benchmark it to see the difference. Is there a chance you can make a video for that?

[ergis]

Very informative video. Learned about the profiling tool too. :)

[RusslanK]

Hi Nick! Thanks for the nice videos & material you make & provide to the public :)
I have never used MediatR library before, however I believe there is another, that might be negative, impact in using this pattern in such a generic way as the library provide. How can you control the lifetime of the handler's instance? Does every time you send a message through the mediator instantiate a new instance of the handler? What happens if you send the message from a loop?

[nothingisreal]

I think from a performance perspective this doesn't matter that much. After all realistically processing a request will do MUCH more memory allocation (DB query, Read/Write XML, create in memory data structures). But I do think that there is a tendency to add more and more indirections into C# projects. And every level of indirection adds more complexity. While the original author of a code might be familiar with all these advance concepts and remember about all the introduced indirections and abstractions someone who needs to maintain the code later will have a very hard time to figure out how things in a code base depend on each other, especially if introducing such an indirection happens in a code file that isn't obviously linked to the code file that depends on it. You must know that e.g. the Mediator package has been added. You must know that this one line of code in the Program.cs is responsible for the coupling. You must know that the service runs transient. All this adds complexity without delivering any direct business value. It is all pluming. This is the wrong direction IMHO.

[olegchernyakov]

Hi Nick,
Thank you for your free content really appreciate it.
I am wondering how will the Fastenpoints perform against mediator, I guess that the Fastenpoints also allocate ram in order to map the objects.

Thank you.

[rtzzz]

It was quite obvious that with all the additional plumbing that Mediatr and CQRS in general require there was going to be some performance impact. I think 8% is not terribly significant. However, we have to remember why CQRS is really in place. The theory is that it improves readability, testing paradigms, and keeps a cleaner more manageable architecture. You can make a case for that I think. In my situation, our company builds enterprise applications for large companies and government with 10's of thousands of potential concurrent users possible. In that scenario, we have been hard-pressed to think that all of the extra plumbing (dozens and dozens of extra nearly empty classes and interface points), that this requires gives a tangible benefit. It does keep code out of the WebAPI controllers which is great. But there are a number of other scenarios including just a straight N layer interface that do the same thing and do not degrade performance. This pattern and some of the others like it then are relegated to really specific situations that most projects do not need. I very much appreciate the quantifiable info that Nick has provided, it further confirms for me in my mind, that Mediatr outside of some very specific situations, is purely an academic exercise.

[Sebazzz]

Do one SQL query or lazy load too many, then optimize that away, and you've gained much more than replacing MediatR.

[MetalKid]

I didn't think the slowness complaint was the basic Mediatr setup. I think it was more when you start adding things to its pipeline/middleware (decorators) that it started to become a problem.

[arkord]

Thank you for this extraordinary example!