Chad ElliottandClaude Opus 5.5 615d8a365e perf(catalog): #1136 index stacks and album membership, sort keys once per photo ...

stack_of, validate_stack and regular-album membership looked a photo up by
scanning every stack or the album's list, so an "In a Stack" or "Album"
smart album, or a query filtered to an album, cost photos x list length
(2.7 s and 0.6-0.8 s at 100k photos). Derived indexes (never saved) answer
them now: built on first use, kept current by the six ops that change
stacks or album photos in apply_inner, so undo, failed-batch rollback and
journal replay follow. A file with a photo in two stacks falls back to the
scan.

query() works out each sort key once (File Name was lower-cased twice per
comparison) and tests `only` as a set; smart-album passes prepare the
filter once; rules name flag, label and kind without formatting per photo.

A property test checks the indexes against a scan through random op
sequences, rollbacks, snapshots, replay, clones and undo.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-10-11 16:48:16 -05:00

..

tests_background.txt

Issue #37: Catalog: compact the log on a background thread with ordered journal boundaries

2026-10-04 16:01:28 -04:00

tests_index.txt

perf(catalog): #1136 index stacks and album membership, sort keys once per photo

2026-10-11 16:48:16 -05:00