Optimize
The query your code runs once per item.
A loop over forty rows that asks the database something inside it is one of the few performance problems that is both obvious in hindsight and invisible in review. MLReps finds it in your code, counts it in the requests you actually served, and shows you the two beside each other.
What it finds in the code
Two rules, and they are the only two. Both are written to be believed rather than to be many: a call counts as a query only against a model your own schema declares, and as being in a loop only when it sits in the body of a loop over a collection of items. Neither is guessed from a name.
And what it refuses to call a problem
Read across four open-source applications before this rule was allowed to report anything:
- A loop that pages, walks or batches — while (hasMore), a step of BATCH_SIZE, a loop over chunks. Batching is the fix this rule would recommend.
- A loop over a list written in the code. Two items is two queries and always will be.
- Seeds, scripts and migrations. A backfill that runs once a quarter is not a request somebody is waiting on.
A miss costs one unreported loop. A false report teaches somebody to ignore the whole screen, which costs all of them.
And what production says about it
The static half can tell you a loop runs one query per item. It cannot tell you how long the list is — that is data the code does not have. Your traces do. Send MLReps your OpenTelemetry spans and it counts the database operations that repeat inside a single request, and names the route they repeat on.
What that count is, exactly
- Spans from requests your system actually served. “Ran 14 times in this request” is a count of what arrived, with the request one click away.
- Kept requests are the slowest and the failed of each route, not a sample of all traffic — so it says a route does this, never in what share of your traffic.
- A request with more spans than were kept gives a floor, and the number says “at least”.
- Query text is never collected, so the same lookup asked three times and one lookup per item read the same from here. Both are worth looking at, and the sentence says both.
What it does not do yet
Optimize is the rung this product is currently building, and this page would rather be short than flattering about it.
- The two rules read Prisma, Drizzle, Sequelize, TypeORM in TypeScript, and Django and SQLAlchemy in Python. Only those. Another ORM gets no findings, not a clean result.
- The Optimization index is calibrated at 0.009, measured across the 5 applications in our corpus that have a database. A scale set by fewer than 11 repositories is set by its one worst member, so this one is called thin everywhere it is shown rather than printed as if it were settled.
- A repository whose checks could not run reads not measured. It is never scored as clean.
- There is no CPU profiling, no memory analysis and no bundle-size work here. Those are real optimisation and this does not do them.
Start in a terminal
One command, in the repository you want read. Your source never leaves the machine on this path.
The measured half needs traces
The repeat counts come from your own OpenTelemetry spans. Nothing is inferred and nothing is sampled on our side.
A finding is not advice
It names the loop, the file and the line, and the operations that loop runs. What to do about it is yours — we produce a patch, you apply it, your tests run it, and you commit it under your name.
The rest of the picture
The same scan draws the architecture, what a change will touch before you merge, and what it could not read.
Everything on this page is a mechanism rather than a promise. Where a number is a floor it says so, and where a check could not run the screen says that instead of showing you a clean result — how that is held.