Performance improvements

Measure first, then use your agent to find and fix real performance issues in a small API.

Goal

Establish a baseline, then work with the agent to find and fix real performance issues. Not speculative micro-optimizations. The exercise teaches evidence over vibes: numbers first, then changes.

Getting started

The repository ships a small .NET minimal API with EF Core and SQLite. Every endpoint works, but each one has a deliberate performance issue.

dotnet run

The API listens on http://localhost:5090. The first run seeds a local SQLite database with 200 customers, between 400 and 2,200 orders, and thousands of order items (at most 15,400 with the current seed ranges).

Try the endpoints:

curl http://localhost:5090/api/orders
curl "http://localhost:5090/api/customers/by-country?country=GB"
curl http://localhost:5090/api/orders/1/total
curl http://localhost:5090/api/skus/csv

Take a baseline

Before you change anything, write down how slow each endpoint is. Wall clock from curl is fine, or use a small load test:

# Wall-clock timing
curl -w "\n%{time_total}s\n" -o /dev/null -s http://localhost:5090/api/orders

# Or hey for a quick load test
hey -n 200 -c 10 http://localhost:5090/api/orders

You will compare against these numbers after each fix.

Workflow

Capture an as-is note: one line per endpoint, metric → value (for example P95 of /api/orders ≈ 420 ms).

Ask the agent to:

list its top hypotheses (I/O, N+1, allocation churn, sync over async, unnecessary serializations),
ground each hypothesis in a file and symbol, not generic advice,
propose one change at a time and re-measure after each.

Apply fixes you agree with. Re-run the same benchmark and record after numbers.

Stop with a before/after table. Even if the improvement is "we proved the hypothesis wrong and moved on," that is a real outcome.

Guardrails

Do not disable security or correctness for speed without calling it out and adding tests.
Beware premature caching. The agent may suggest a cache when the real fix is fewer round trips.
If results are noisy, run multiple iterations or fix concurrency so "faster" is defensible.

Done when

You have a reproducible measurement script or set of curl commands, a before/after summary, and one line describing what you would monitor in production if this shipped (a metric name or a dashboard panel).

Optional stretch

Add a regression test or performance budget in CI (a smoke benchmark) if your stack supports it quickly.