1. Severity: Medium
2. File and line: `src/DarcsWeb/Darcs.hs:204-210`, `app/Main.hs:254-257`, `src/DarcsWeb/Html.hs:123-126`
3. The inefficiency: `getRepoSummary` avoids the old multi-pass repo reopenings, but it still materializes `PatchSummary` for every patch in the repository via `mapRL extractPatchListing patchRL`, then returns the full tag list to a page that only renders `take 10 recentPatches`, `take 5 tags`, and `length tags > 5`. That keeps `/repo/:name/summary` proportional to total history size in both CPU and allocation pressure, and it pays the `summary p` rendering cost for patches that the summary page will never show.
4. When it becomes a real problem: This shows up on repositories with large histories, or on instances where the summary page is the common entry point and gets refreshed often. Under that load, each summary request still walks the whole patch set and builds far more `PatchSummary` data than the template consumes, so latency scales with repository age rather than with the small amount of information visible on the page.
5. A concrete optimization direction: Keep the single-repository fast path, but replace `allSummaries` with a strict summary-specific fold over `patchRL` that accumulates only `(lastDate, patchCount, first 10 recent patches, first 6 tags/hasMoreTags)`. Use `PatchInfo` alone for `lastDate` and `patchCount`, and only call `extractPatchListing` for patches that will actually be displayed or counted toward the small tag preview. If other routes still need full patch or tag lists, keep those as separate helpers instead of making the summary endpoint construct them eagerly.
