Performance

Most guesses about performance are wrong. That is not a criticism of anyone's judgement; it is what happens when a request passes through routing, binding, validation, your code, an ORM, a database, a network and serialisation, and you are asked to name which part took the longest.

The consequence is a method rather than a list of tricks. Measure, find where the time actually goes, change that one thing, measure again. The profiler is the arbiter. Code that looks slow and code that is slow overlap far less than people expect.

Measure the right number as well. An average hides the problem: if ninety-five requests take 20ms and five take four seconds, the average looks acceptable and one caller in twenty is having a bad time. Look at the 95th and 99th percentiles, because those are the requests people complain about.

// ---- Before: 1 + N queries, every column, tracked entities ----
List<Employee> all = await db.Employees.ToListAsync(cancellationToken);

List<EmployeeListItem> slow = [];
foreach (Employee employee in all)
{
    // A separate query per employee to reach the department name.
    Department department = await db.Departments
        .FirstAsync(d => d.Id == employee.DepartmentId, cancellationToken);

    slow.Add(new EmployeeListItem(employee.Id, employee.FullName, department.Name));
}

// ---- After: one query, three columns, no tracking, and a page ----
List<EmployeeListItem> fast = await db.Employees
    .AsNoTracking()
    .Where(e => e.IsActive)
    .OrderBy(e => e.FullName)
    .Select(e => new EmployeeListItem(e.Id, e.FullName, e.Department.Name))
    .Skip((page - 1) * pageSize)
    .Take(pageSize)
    .ToListAsync(cancellationToken);

// ---- Before: blocks a thread pool thread for the whole call ----
EmployeeResponse blocked = payrollClient.GetSummaryAsync(id, cancellationToken).Result;

// ---- After: the thread is released while the call is in flight ----
EmployeeResponse released = await payrollClient.GetSummaryAsync(id, cancellationToken);

• The loop is the N+1. With 2,000 active employees it issues 2,001 queries, and each one carries its own round trip. The fix is not a faster loop; it is not having a loop.
• Select projects to exactly the fields the client needs, so the database returns three columns instead of every column of two tables. The projection also reaches the department name through the navigation property, which becomes a join in one query.
• AsNoTracking tells the ORM not to keep change-tracking snapshots of what it loaded. For a read-only list that work is pure overhead, and it grows with the number of rows.
• Skip and Take add paging. An endpoint with no upper bound on result size has a performance problem that is waiting for your data to grow rather than one you have yet.
• The .Result call is the quieter of the two problems and often the more damaging. It holds a thread pool thread for the entire duration of a network call, so under load the pool starves and unrelated requests queue behind it. Await it instead, all the way up.