#377 Performance improvements in .NET 6


Five C# Features You Might Not Know

A quick tour about five C# features that even experienced developers might not know: from variable scopes to the top-level statements and others.

this week's favorite

Performance improvements in .NET 6

The dotnet/runtime repository is the home of .NET’s runtimes, runtime hosts, and core libraries. Since its main branch forked a year or so ago to be for .NET 6, there have been over 6500 merged PRs (pull requests) into the branch for the release, and that’s excluding automated PRs from bots that do things like flow dependency version updates between repos (not to discount the bots’ contributions; after all, they’ve actually received interview offers by email from recruiters who just possibly weren’t being particularly discerning with their candidate pool).

Domain-driven refactoring: Defactoring and pushing behavior down

In the last post, we looked at our procedural handler and pulled behavior out that called to external services into its own domain service. This let our handler become more unit testable by creating a test seam, and we could now alter the behavior of the abstraction through mocks/stubs etc.

.NET Multi-platform App UI for Linux

.NET Multi-platform App UI, a framework for building native device applications spanning mobile, tablet, and desktop.

6 hidden productivity gems in ReSharper and Rider

One of the most impressive productivity tools in .NET development is ReSharper. I keep getting blown away by its capabilities with each release. Don’t get me wrong here, I love Visual Studio, and it’s getting immensely better as well. But whenever I think Visual Studio caught up, I discover some new amazing feature that leaves me dependent on ReSharper and Rider yet again.

Large numbers of bindings with RabbitMQ

RabbitMQ (or more specifically the AMQP protocol) provides a degree of flexibility over other message-queue solutions with its exchange-binding-queue model. Some possible solutions to scaling or business issues result in large numbers of bindings being created, perhaps thousands per queue. We tested RabbitMQ to find out what the binding performance limits were and present the results in this post. It seems that large numbers of bindings are not in themselves a performance issue, but on a RabbitMQ cluster, “binding churn” the rate at which they are created and destroyed can have a large impact on message delivery and because bindings can take time to propagate through the cluster there is the possibility of message loss.


Would you like to become a sponsor and advertise in one of the issues? Check out our media kit and get in touch.