The board named the screen; the count named the call
The speed board said the till first call was slow. Counting its statements said why: four reads in a line, each keyed on one venue, none needing another.
For several days the board had shown the till's first screen over budget and named the same call as the slowest thing it did while booting: the request that fetches the tile layout and the best-seller rankings. Seventeen cold loads one morning, every one of them waiting around 800 milliseconds on that call.
The board can tell you which call. It cannot tell you why. For that we have a bench that runs a route against a real database and counts two things: how many statements it issues, and how many times it stops to wait for one before issuing the next. We pointed it at the Menu screen's routes because that screen was also red, and the till's boot call turned up in the list beside them.
Four reads, four waits
The menu route itself issued twenty-two statements in one wave: busy, but one wait. The layout route issued four statements and waited four times. The saved tile layout, then the all-time best sellers, then the last thirty days, then the last seven. Each keyed on the venue in the address. None needed another's answer. They ran one after another because they were written one after another.
From a till in a UK food hall each of those waits is a trip to a database in the eastern United States. Four trips where one would do, on the one call every register in the country makes when it switches on.
One wave
The four now go out together. The test was written first and run against the unfixed route, where it failed by name on four serial steps, and passes at one. It also pins the answers: the saved tiles come back parsed, the rankings are what they were (fries ahead of the burger across all time, the burger alone in both recent windows, a refunded line and a pending order counting nowhere), and a venue with no layout and no sales gets empty lists rather than an error.
Measured on the live service after the deploy, from Europe, the route takes 110 to 340 milliseconds for one wave of four statements, three of which add up a month of order lines, so this is not a single-trip floor. The work is real; it just no longer queues.
What was not fixed
The till's cold load. Seventeen of seventeen loads that morning were the first screen after opening the app, and the first screen pays for downloading the app itself. That cost is the size of the register's code and stylesheets, not the speed of any one call, and shrinking it is a product decision about what the till carries, not a route fix. It is on the owner's list. This change takes roughly a quarter of a second off the first call from the UK and leaves the shell exactly where it was.
For anyone running a floor
A report that says which station is slow has done half the work. The other half is standing at that station and counting what it does. Four separate trips to the walk-in for one dish is slow in a way that no faster walking fixes; you fix it by carrying four things at once. The board found the station. The count found the trips.