Lightroom Classic becomes unresponsive within seconds of ordinary Library interaction and stays that way until the application is relaunched.

Thanks for replying. Answers below, with traces attached.

TRACES: No, raw traces are not in the original report; it contained a summarised stack only. I’ve attached:

• sample-lightroom.txt.gz: 10s user-space sample(1) during the hang
• spindump-lightroom.txt: 10s spindump, trimmed to the Lightroom process
• counters.txt: process/VM counters at time of capture
• lightroom-system-info.txt: Lightroom's own System Info block

Captured with the hang active, after ~60 seconds of scrolling the Library grid by hand. (Note that username, hostname, and home paths are scrubbed.)

The spindump is trimmed to Lightroom's own section (the full system-wide capture covered 1,038 processes). More than happy to send the untrimmed 27 MB original if useful.

Key figure from the spindump main thread over the 10s window:

• DispatchQueue "com.apple.main-thread": 1001 samples
• CPU time 9.890s: 31.0G cycles, 88.3G instructions, 0.35c/i, 3.14GHz avg

That is 9.89 seconds of CPU in a 10-second window on the main thread alone. In the accompanying sample(1), 63% of main-thread samples are inside lua_pcall -> lua_resume; in earlier captures on this machine it reaches 99%.

BRAND-NEW SMALL CATALOG: No, the hang does not occur with a small catalog. It is a gradient with photo-record count, not a threshold. Measured on a catalog stripped of all
develop settings, metadata, sync state, and analysis data, with zero-byte placeholder files, so record count was the only variable:

• 2,208 photos: 0%  of main thread in Lua; clean
• 7,714 photos: <=5%; clean
• 24,000 photos: 0%; clean
• 32,000 photos: 23%; degraded and perceptible
• 40,748 photos: 99%; pinned, continuous

A brand-new empty catalog is also clean, as is a 500-photo subset of my own catalog, tested with the same hand interaction.

Note the composition result, which may be more useful than the counts: with my real (un-stripped) catalog, the OLDEST 20,000 records ran clean while the NEWEST 20,748 hung. Same record count, opposite outcome. After stripping develop settings, metadata, sync, and analysis data, that asymmetry disappeared and only the count mattered. So something in the per-record data raises the cost, but removing all of it does not eliminate the hang, as it only raises the count at which it appears.

ONE THING FOR WHOEVER REPRODUCES THIS: Scripted activation does not trigger it. AppleScript “activate” between apps runs clean indefinitely on a catalog that hangs within ~20 seconds of real hand scrolling. An automated harness driving activation events will report this as not-reproducible. It needs genuine interaction.