DEV Community: chandana pushpakumara

EF Core 10 Performance Issue

chandana pushpakumara — Mon, 30 Mar 2026 10:12:00 +0000

The most common performance issue is fetching a list of items and then calling the database again for each child record.

The “Slow” Method(N+1):

var blogs = await context.Blogs.ToListAsync(); 
foreach (var blog in blogs)
{
    var posts = await context.Posts.Where(p => p.BlogId == blog.Id).ToListAsync();
}

The EF Core 10 “Fast” Method(Filtered Include):

var blogs = await context.Blogs
    .Include(b => b.Posts.Where(p => p.IsPublished)) // Filtered Include
    .ToListAsync();

EF Core 10 Performance Result

Here I used 100000 records. My benchmark result shows that the N+1 query problem was over 280x slower than using Include(). However, optimizations like projection AsNoTracking() showed minimal gains in small datasets, highlighting that performance tuning depends heavily on scale.

I wrote a detailed article about 4 other optimization traps here: EF Core 10 Performance: Fixing 5 Common Slow Queries.

Native AOT in .NET 10: Everything for C# Developers

chandana pushpakumara — Sun, 22 Mar 2026 10:06:26 +0000

Honestly, C# has had an incredible run over the last twenty years. It’s easily one of the most balanced languages out there, but I think people often forget how much of that heavy lifting is actually done by the JIT compiler. The way it optimizes everything on the fly at runtime is really what gives it that performance edge.

But in 2026, Microsoft introduced Native AOT in .NET 10. The performance floor has shifted. Now that .NET 10 has fully leaned into Native AOT, the trade-offs have changed. In a world of real-time AI and massive container clusters, 'fast enough' doesn't cut it. We need that immediate execution and smaller footprint to stay competitive, especially when you're scaling a thousand instances where every megabyte of overhead adds up.

This is where Native AOT (Ahead-of-Time compilation) in .NET 10 becomes a game changer.

Traditional Model (JIT)

Code compiled to Intermediate Language (IL)
JIT compiles IL → machine code at runtime
Pros: Flexibility, dynamic optimizations
Cons: Startup delay, higher memory usage

Native AOT Model

Code compiled directly into machine code during publish
No JIT compilation required at runtime
Pros: Instant startup, smaller footprint, improved security

Project: Native AOT vs JIT Performance Benchmark

🧱 Solution Structure
AOTPerformanceDemo/ ├── JitApp/ (Standard .NET Console App) ├── AotApp/ (Native AOT Console App) └── BenchmarkRunner/ (Measures performance)

Create the Solution

dotnet new sln -n AOTPerformanceDemo
dotnet new console -n JitApp
dotnet new console -n AotApp
dotnet new console -n BenchmarkRunner
dotnet sln add JitApp
dotnet sln add AotApp
dotnet sln add BenchmarkRunner

Add Sample Workload (Same Code in Both Apps)
Replace Program.cs in JitApp and AotApp:

using System.Diagnostics;

Console.WriteLine("App starting...");
var sw = Stopwatch.StartNew();
var result = HeavyComputation();

sw.Stop();
Console.WriteLine($"Result: {result}");
Console.WriteLine($"Execution Time: {sw.ElapsedMilliseconds} ms");

static long HeavyComputation()
{
    long sum = 0;    for (int i = 0; i < 10_000_000; i++)
    {
        sum += i;
    }    return sum;
}

Enable Native AOT (Only for AotApp)
Edit AotApp.csproj:

<Project Sdk="Microsoft.NET.Sdk">  
<PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>

    <!-- Enable Native AOT -->
    <PublishAot>true</PublishAot>    
    <!-- Reduce size -->
    <PublishTrimmed>true</PublishTrimmed>
    <InvariantGlobalization>true</InvariantGlobalization>
  </PropertyGroup>
</Project>

Build JIT App

dotnet build JitApp -c Release

Publish Native AOT App

dotnet publish AotApp -c Release -r win-x64

Benchmark Runner

using System.Diagnostics;

RunTest("JIT App", @"..\JitApp\bin\Release\net10.0\JitApp.exe");
RunTest("Native AOT App", @"..\AotApp\bin\Release\net10.0\win-x64\publish\AotApp.exe"); 

static void RunTest(string name, string path)
{
    Console.WriteLine($"\nRunning {name}..."); 
    var sw = Stopwatch.StartNew(); 

    var process = new Process
    {
        StartInfo = new ProcessStartInfo
        {
            FileName = path,
            RedirectStandardOutput = true,
            UseShellExecute = false
        }
    }; 

    process.Start();
    process.WaitForExit(); 
    sw.Stop(); 

    Console.WriteLine($"{name} Total Time (including startup): {sw.ElapsedMilliseconds} ms");
}

Run Benchmark

dotnet run --project BenchmarkRunner -c Release

Find the complete implementation and benchmarking project on GitHub

Result

Based on the results shown in my terminal, here is a visual comparison of the performance gap between the standard JIT approach and the new Native AOT in .NET 10.

The data reflects the following metrics from my run:

JIT App (Standard): 170 ms total execution time.
Native AOT App: 69 ms total execution time.

This represents a ~60% reduction in startup and execution time for the Native AOT version.
If you interesting you can read my full article

C# Memory Management: Using Span and Memory for Zero-Allocation

chandana pushpakumara — Mon, 16 Mar 2026 04:33:32 +0000

Introduction: The Cost of the Garbage Collector (GC)

One of the biggest advantages of modern .NET development is managed memory. Developers do not need to concern about manual memory allocation and deallocation like in C or C++. The .NET Garbage Collector (GC) get that concern on behalf of programmers, it automatically handles memory cleanup, making development safer and more productive. Here is the master class of C# memory management

However, “managed code” does not mean free performance.

When applications allocate too many objects on the heap, the Garbage Collector must frequently run to get back memory. This is the reason for several performance challenges:

GC Pressure – Frequent object allocations increase the workload for the garbage collector.
Stop-the-world pauses – The GC temporarily pauses application threads to get back memory.
Heap fragmentation – Repeated allocations and deallocations create ineffective memory layouts.

In most enterprise applications, this overhead is acceptable. But in low-latency environments, even a small startup can cause a serious problem

What Are Span and Memory?

Span is one of the most advanced memory allocation method adding to .NET. It represents a lightweight view over contiguous memory.

Key characteristics:

Can point to stack memory
Can point to heap arrays
Does not allocate memory
Extremely fast
Stack-only structure

Example:

Span<int> numbers = stackalloc int[5]; numbers[0] = 10; numbers[1] = 20; numbers[2] = 30;

Here, we allocate an array directly on the stack. Benifit of this memory allocation does not involve garbage collector allocation. The user can experience faster execution and automatic memory release.

Because Span is stack-only, it cannot be used in async methods.

This is where Memory comes into the picture. Memory Provides a heap-safe wrapper around memory buffers.

Example:

Memory<byte> buffer = new byte[1024]; Span<byte> span = buffer.Span;

Zero-Allocation Patterns: Practical Examples

Now we are going to write a C# code for veryfy how these allocations are working. I create sample .NET console application for expain these zero allocation pattern
Over 15 year experiese, I can say most of the developers create extra allocations when working with strings. This is a way to reduce it.

The Scenario: Extracting a "Product Code" from a long String

In traditional C#, developers use .Substring() a method that creates a new string object on the heap every time it is called. If you are processing a 1GB file, this creates massive Garbage Collector (GC) pressure.

The Project Setup

Create a Console Application for your benchmarks. Mixing benchmarks into your main Web API can skew the results due to background service interference.

Create a new console app dotnet new console -n MyPerformanceLab cd MyPerformanceLab Add the BenchmarkDotNet nuget package (the industry standard)

Designing Your Benchmark Class

Create a new file called StringPerformance.cs. Use the [MemoryDiagnoser] attribute; this is what adds the high-value "Allocated Memory" column to your results.

`using BenchmarkDotNet.Attributes;

namespace MyPerformanceLab
{
[MemoryDiagnoser]
[RankColumn]
public class StringPerformance
{
private const string TelemetryData = "ID:9982-XYZ-2026-LOG-DATA";
private const int Length = 8;

    [Benchmark(Baseline = true)]
    public string UsingSubstring()
    {
        int start = TelemetryData.IndexOf(':') + 1;
        return TelemetryData.Substring(start, Length);
    }

    [Benchmark]
    public ReadOnlySpan<char> UsingSpan()
    {
        ReadOnlySpan<char> span = TelemetryData.AsSpan();
        int start = span.IndexOf(':') + 1;
        return span.Slice(start, Length);
    }
}

Triggering the Run

In your Program.cs, replace the default code with the BenchmarkRunner.

`using BenchmarkDotNet.Running;

// This triggers the heavy-duty measurement cycle
var summary = BenchmarkRunner.Run();`

This is my result. It unbelievable

Output: You can clearly see that using Span is 3x time faster than using Substring

You can also download the full source code for these benchmarks on my GitHub Repository.

This is my full article

The CommandType Enumeration Value 512 Is Not Supported – Complete Fix in ASP.NET / .NET Framework

chandana pushpakumara — Thu, 12 Mar 2026 14:54:05 +0000

When Developers working with ADO.NET and SQL Server in .NET Framework or ASP.NET applications may get this error: “The CommandType enumeration value 512 is not supported by the .NET Framework SqlClient Data Provider” in their programming life. This error occurs when executing database commands using ADO.NET with an incorrect CommandType. The concern of this, SQL Server provider does not support CommandType.TableDirect (value 512).

Reason behind this behavior: Supported only by OleDb providers.

Error Code

cmd.CommandType = CommandType.TableDirect;

How to fix this error

✔ Solution 1 – Use CommandType.Text

For normal SQL queries:

cmd.CommandType = CommandType.Text;
cmd.CommandText = "SELECT * FROM Employees";

✔ Solution 2 – Use StoredProcedure

For stored procedures:

cmd.CommandType = CommandType.StoredProcedure;
cmd.CommandText = "GetEmployees";