Profile ASP.NET Core Endpoint Allocations with BenchmarkDotNet

You’ve optimized your application’s logic, but sometimes performance bottlenecks stem from unexpected memory allocations. Identifying where and why your ASP.NET Core endpoints are creating garbage can be a tedious manual process. This is where combining the power of BenchmarkDotNet for microbenchmarking with Claude Code for intelligent analysis can significantly speed up your debugging workflow.

BenchmarkDotNet is the de facto standard for benchmarking .NET code, providing detailed statistics, including allocations. By creating a simple benchmark for your endpoint, you can get a baseline measurement. Claude Code can then help you interpret these results and even suggest refactorings to reduce those allocations.

Here’s a basic setup for benchmarking an ASP.NET Core endpoint. Ensure you have the BenchmarkDotNet NuGet package installed. You’ll need to simulate the HttpContext and HttpRequest for your endpoint in a benchmarkable way.

using BenchmarkDotNet.Attributes;
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using System.Threading.Tasks;

public class EndpointBenchmark
{
    private readonly TestController _controller;
    private readonly DefaultHttpContext _httpContext;

    public EndpointBenchmark()
    {
        _controller = new TestController();
        _httpContext = new DefaultHttpContext();
        _httpContext.Request.Method = "GET";
        _httpContext.Response.Body = new System.IO.MemoryStream(); // Important for some endpoint behaviors
    }

    [Benchmark]
    public async Task<IActionResult> GetGreeting()
    {
        // Simulate setting up necessary parts of the context if your controller relies on them
        _controller.ControllerContext = new ControllerContext { HttpContext = _httpContext };
        return await _controller.Get("World");
    }

    // Example Controller (place in a separate file or within the benchmark project)
    public class TestController : ControllerBase
    {
        [HttpGet]
        public async Task<IActionResult> Get(string name)
        {
            // Simulate some work that might allocate
            var message = $"Hello, {name}!";
            await Task.Delay(10); // Simulate async work
            return Ok(message);
        }
    }
}

After running BenchmarkDotNet (e.g., via dotnet run -c Release in your benchmark project), you’ll see allocation statistics. If you see a high number of allocations, you can feed these results to Claude Code for analysis. For example, if the message string creation is identified as a significant allocation source, Claude Code might suggest using string.Format with pre-allocated format strings or exploring StringBuilder for more complex concatenations if performance demands it. A potential gotcha is that simulating the HttpContext perfectly can be complex; ensure your benchmark setup accurately reflects the dependencies your endpoint truly relies on.

Try it: Add the BenchmarkDotNet NuGet package to a new console application, create a simple ControllerBase with an endpoint, and write a Benchmark class to measure its performance and allocations.