this post was submitted on 27 Feb 2024
2 points (100.0% liked)

Talks

78 readers
2 users here now

A community to share and discuss good (conference) talks in/about software industry.

Please try to listen to a significant chunk of the talks before engaging in discussion and try to avoid responding just to the title of the talk.

Rules

Credits

Icon base by Lorc under CC BY 3.0 with modifications to add a gradient

founded 8 months ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] RonSijm 2 points 8 months ago
  1. He doesn’t mention performance impacts, but I suspect this would impact performance.

It looks like he's using an Analyzer to generate interceptors. More detailed on how those interceptors works is pretty good explained here: https://www.youtube.com/watch?v=91xir2oUQPg

So performance wise, this shouldn't change the performance impact any more than manually wiring in loggers on every level. - It might slow down the compile time by a little bit though.

A project that does something very similar but for Mediators is Mediator.SourceGenerator - an alternative to MediatR - but that project does it for Mediators instead of logging

The "original" way of doing something like this was by using Castle DynamicProxy, and creating an interceptor at runtime. Which would affect runtime performance more than doing it compile time

And another alternative way of doing the same thing would be using Fody - Creating logging attributes or interfaces, and then using Fody to wire in logging. Though Fody would be doing it during post-compile though an IL Weaver.

So this Roslyn Source Generator weaving approach is basically the best way to approach this