mirror of
https://github.com/rommapp/romm.git
synced 2026-06-28 14:56:01 +00:00
67f3474d3f
The /api/roms list endpoint did several O(library) computations on every request. On a 100k-rom library each request took 4-5s. This addresses the dominant costs, all measured on a real 100k-rom MariaDB. - Cache rom_id_index: the full ordered id list backing virtual scroll was recomputed (the sibling-dedup window over the whole library) on every request, even limit=1, and shipped uncached. Memoise the unscoped scan under the same versioned cache as the other sidecars. 2815ms -> 7ms on hit. - Slim the sibling-dedup query: the inner derived table materialized all of Rom (including JSON metadata blobs) for 100k rows, and carried a wide unused fs_name_no_ext through the window's temp table (spilling the sort to disk), plus a pointless inner ORDER BY. Select only the columns the window needs. 2.79s -> 0.86s, identical results, no schema change. - Rewrite with_char_index: replace row_number() over the whole library (full materialization + double filesort) with a per-letter COUNT and an accumulate. Identical output, drops a filesort layer. - Add idx_roms_sibling_cover covering index for the sibling_roms view self-join, so the 7-way metadata-id OR resolves from the index instead of reading wide rows per parent. ~8x on dense pages warm, far more cold. AI assistance: written with Claude Code (diagnosis, query rewrites, migration, tests). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>