Pillar guide

Performance: a working guide for .NET developers

Updated May 07, 2026

This guide is the entry point for Performance on dotnetnews.co. It collects the writing we have curated on Performance into one page so you can orient yourself fast: what Performance is in working .NET projects today, why it matters, what to read next, and where teams keep tripping over the same problems.

If you want the full back-catalog, the Performance topic page lists every issue we have ever tagged with performance (currently 244 curated issues). This pillar narrows that down to the pieces that earn re-reading and threads them into a working narrative.

What Performance actually is in a working .NET project

In .NET teams we see in 2025 and 2026, Performance is rarely a single feature pulled off a shelf. It is a set of practices that touches your build, your test loop, and the way you describe your system to the next person who joins. It is also moving target: the .NET 8 -> .NET 10 cycle changed defaults, the C# language has shipped new sugar nearly every year, and the tooling around Performance has consolidated faster than most teams can keep up with.

That makes a curated reading map valuable. Most working developers do not have the cycles to read every release-notes post, every Azure devblog, and every Medium write-up. The .NET News Daily archive does that triage. This page lifts the most useful threads out of that archive and points to where to start.

If you are new to Performance or coming back after a long break, read the first three issues in the reading map below in order. They give you the current vocabulary plus a sense of where the rough edges live.

Why Performance matters for .NET teams in 2026

Three working observations from the curation work:

  • The defaults moved. What used to be ceremony in older .NET projects is now scaffolded out of the box, but only if you start a new project. Most teams are not on the latest scaffold; that’s where Performance questions surface.
  • The community absorbed Azure-shaped opinions. A lot of Performance writing in the last 18 months has been “this is how we did it on Azure” with the surrounding pattern still applicable everywhere. Read for the pattern, not the cloud.
  • The toolchain rewards small upgrades. Most teams that pay down a single Performance debt every release end up months ahead of teams that wait for a “big rewrite”. The reading map below is biased toward those small upgrades.

The pieces below were curated because they keep coming up in real conversations: PRs, retros, code reviews, and the kind of question that lands in a Slack channel at 4pm on a Friday.

Reading map: start here

The first three issues are the ones to read in order. The rest are good as you need them.

1. Issue #451 - C# 14, validation, and ASP.NET logging

Start here (1 of 3). A varied .NET roundup covering collection optimization, VS Code 1.119, ASP.NET Core request logging, auth basics, and Web API CRUD with EF Core. (2026-05-08)

2. Issue #449 - Profiling, caching, async internals

Start here (2 of 3). A varied .NET mix covering profiling-first performance work, Postgres distributed caching on Azure, Hangfire tuning, Kafka consumers, and memory internals. (2026-05-06)

3. Issue #448 - EF Core migrations, async bugs, API versioning

Start here (3 of 3). Covers EF Core 10 migration cleanup and deployment, .NET 10 API versioning with OpenAPI, structured logging, Hangfire, LINQ, and memory pitfalls. (2026-05-05)

4. Issue #447 - LLMs, DI, security and performance

Coverage spans TorchSharp GPT internals, DI lifetimes, ASP.NET Core privilege escalation, CSV parsing, ADO.NET ergonomics, and concurrency design. (2026-05-04)

5. Issue #446 - Agent storage, AOT addons, security fix

Covers Agent Framework storage and token tradeoffs, the .NET 10 OOB security patch, Native AOT Node.js addons, caching, and core C# refreshers. (2026-05-01)

6. Issue #444 - JSON choices, API reliability, and C# internals

Covers Newtonsoft vs System.Text.Json, ASP.NET Core error handling, Azure DevOps CI, Cosmos DB cost tuning, and core C# design tradeoffs. (2026-04-29)

7. Issue #443 - ASP.NET Core, EF Core & AI security

A varied .NET roundup covering .NET 10 ASP.NET Core updates, EF Core query pitfalls, Blazor architecture, Entra ID auth, and AI security. (2026-04-28)

8. Issue #442 - Span, EF Core, HTTP/3 and DI

Coverage includes ReadOnlySpan on .NET Framework, CRON and RRule evaluation, EF Core identity insert costs, feature flags, Blazor, and AI workflows. (2026-04-27)

9. Issue #441 - Middleware, EF Core, and .slnx

A varied .NET roundup covering middleware internals, Minimal API REPR, Azure database pricing, JWT auth, EF Core tuning, and April servicing updates. (2026-04-24)

10. Issue #439 - API versioning, EF Core, and AI agents

Covers xUnit testing, Azure Functions in Docker, HttpClientFactory, EF Core loading and translation, plus ASP.NET Core support guidance. (2026-04-22)

11. Issue #437 - EF Core, Polly v8, and local AI

Coverage includes EF Core query tuning, testing seams, Span-based parsing, Visual Studio Azure debugging, and local LlamaSharp AI in .NET. (2026-04-20)

12. Issue #435 - HybridCache, LINQ traps, API performance

Coverage spans .NET 10 HybridCache, deeper health checks, LINQ execution costs, legacy Excel handling, project structure, and test library design. (2026-04-16)

13. Issue #434 - EF Core, CQRS, and Visual Studio tips

Coverage includes EF Core performance and change tracking, a MediatR-free CQRS dispatcher, Visual Studio window control, analyzers, and C# 14. (2026-04-15)

14. Issue #433 - EF Core, C# 14, and clean code tradeoffs

Coverage includes EF Core transactions and views, C# 13/14 language features, LINQ performance traps, multi-tenant architecture, and VS Code AI tooling. (2026-04-14)

Looking for the rest? The full Performance archive lives on the Performance topic page.

Common pitfalls

Patterns we see across the curated archive when teams trip on Performance:

1. Treating Performance as a one-off project

The teams that handle Performance cleanly fold it into every release as small, ratcheting upgrades. Teams that defer it end up with a quarter-long tax. Several issues in the reading map above describe exactly this gap; the most recent one is a good five-minute read on the topic.

2. Reaching for a library before reading the standard library

The .NET BCL keeps absorbing what used to be third-party. Teams that stay on libraries from 2020 are paying for code the runtime now ships. Look at how recent issues handle the same problem with built-ins before you adopt a new dependency.

3. Skipping the test loop

If a Performance change does not have a test that fails before the change and passes after, you cannot trust the upgrade. The curated archive includes several walkthroughs of test setups that catch regressions early. Use them.

4. Confusing the documentation surface for the production surface

What works in a docs example often does not survive a production load profile. Read the curated issues for the post-mortem-flavored ones, not the marketing-flavored ones.

5. Underestimating the cost of un-tagged dependencies

A surprising number of Performance regressions in the curated archive came from a transitive dependency, not from the team’s own code. The fix is dull but worth doing once: pin versions, audit the dependency tree on each release, and treat indirect updates the same way you would treat direct ones. Several issues in the reading map walk through real-world examples of this exact pattern.

6. Skipping observability until production breaks

Teams that wait until Performance causes a customer-facing incident to add tracing or structured logs end up paying the worst version of that bill. The curated archive includes several walkthroughs of the cheapest observability slices that catch Performance regressions before they ship; they are listed under the observability topic.

FAQ

Q: I have never touched Performance. Where do I start? A: The first three entries in the reading map above are sequenced exactly for that. Read them in order; expect to spend an hour. Then bookmark the topic page and check it once a week.

Q: Does Performance change much between .NET versions? A: Yes. The patterns are stable but the defaults move. The curated archive is dated; read the most recent issue first to see the current shape, then read older issues for the why.

Q: How does Performance interact with the rest of the .NET stack? A: It depends on which slice you mean. The reading map above is intentionally cross-cutting: a few entries cover the runtime, a few cover the tooling, a few cover the libraries built on top. Pick the slice that matches your project today.

Q: I want to share this with my team. What is the one-page summary? A: This page. Send the link. The topic page is the deeper archive when they want more.

Q: What if a curated issue is out of date? A: Curated issues stay in the archive even when the underlying tech moves. The pillar page is updated quarterly to keep the order honest. If you spot a stale recommendation, reply to any issue and we will refresh.

  • C# - the working guide for the C# surface area.
  • EF Core - the working guide for the EF Core surface area.
  • .NET Core - the working guide for the .NET Core surface area.
  • ASP.NET Core - the working guide for the ASP.NET Core surface area.

Subscribe

Get the daily digest. Curated Performance issues land in your inbox the morning they go live. Subscribe to .NET News Daily.