Closed a production performance incident by replacing an ORM-driven client-side scan with a server-side filtered index — collapsing a 20-second cloning operation to 200 ms and removing an entire class of customer support tickets.
Context
A core operation on the platform was cloning large organizational tree structures. Customers cloning real-world structures kept hitting timeouts, the support queue was filling up, and the .NET application was under steady GC pressure. The first proposed fix was an AI-suggested patch to drop a few ORM joins.
The problem
Removing joins was a cosmetic change that wouldn't touch the actual bottleneck. I needed to find the real cause and convince my manager — under high-stress incident pressure — to walk away from a "quick" patch and commit to a fundamental fix instead.
Approach
Captured the SQL Server execution plan and ran a .NET memory profiler to characterize the bottleneck with hard data.
Identified the root cause: the ORM was failing to translate one filter into SQL and falling back to client-side evaluation, pulling millions of rows into the app process for a Table Scan just to locate a single root node.
Designed a targeted filtered index in SQL Server so the database — not the application — did the filtering.
Aligned with the engineering manager by sharing the execution plan and GC allocation graph instead of arguing on opinion.