“The week overview is slow” is an observation, not a diagnosis. Whoever guesses now is likely to optimize the spot they think is expensive, and the real cause stays. In this lesson you learn to find a slow spot with tools, to justify a change with numbers and to record the improvement so that it is not lost with the next pull request. At the end the Kladde’s week overview is fast, and a test watches over it.
New in this lesson:
| Tool or package | Version | What for |
|---|---|---|
dotnet-counters, dotnet-trace, dotnet-gcdump |
10.0.750501 | diagnostic tools from Microsoft, as local tools |
BenchmarkDotNet |
0.15.8 | small, precise measurements; open source under MIT, not from Microsoft (check the license before the course begins) |
Microsoft.EntityFrameworkCore.Sqlite |
10.0.14 | only for the exercise project: an in-memory database, no container |
The procedure
Performance work always follows the same procedure, and each step has a result that you write down:
- Goal. How fast should it be? From lesson 3.8.6 you have a goal for the 95th percentile. Without a goal you do not know when you are done.
- Measurement. How fast is it now, under what load? The load generator from 3.8.6, the telemetry from 3.4.
- Hypothesis. A tool shows where the time goes. From that comes a hypothesis: “The overview issues a query of its own for every appointment.”
- One change. Exactly one, so that you know what worked.
- New measurement, under the same conditions. If it does not get better, you take the change back, even if it looks nice.