Lightroom Desktop 9.6 Local mode: first open of Enhanced/Flattened raw stalls UI 20–40 s on a single core; viewed photos retain 2–3 GB each until a purge rebuilds the whole folder

Description of Issue
In Local mode, opening a CR3 that has Enhance (Denoise) or "Flattened" edits (Denoise plus generative remove baked in) blocks the Develop UI for 20–40 seconds. During that time the process uses one CPU core (100–180 % of 1800 %), no disk I/O, no GPU. Photos without AI edits open instantly. A sampled stack shows the dispatch queue "WFModelConnectionImp.lua" running zlib deflate inside CameraRaw (offsets +0xfe6be0…+0xfe73b8 and +0x19bc804 from the CameraRaw load address; the inner loop is zlib longest_match, constants 258/262).

In addition, every photo viewed in the loupe keeps 2–3 GB in the process after moving on. When Camera Raw memory reaches ~80 % of its limit (22.5 GB here), Lightroom runs ag.develop.purge_memory and then renderToDNG for all Flattened photos, so the 20–40 s stalls repeat for the whole folder. Leaving the loupe for the grid triggers the same purge. Zooming to 200–400 % on a Flattened photo adds ~14 GB at once and triggers it too. On 2026-10-26 the process was killed by Jetsam at 24.2 GB.

Flattened photos carry inline big tables in the .acr sidecar XMP (crs:Table_<digest> for crs:CompressedSettings and crs:OriginalInstanceDigest), 13–76 MB per photo, 551 MB over 15 photos in one folder. This looks like the payload being deflated on the catalog-model queue.

Lightroom Desktop Version Number (Help > System Info)

Flattened photos carry inline big tables in the .acr sidecar XMP (crs:Table_<digest> for crs:CompressedSettings and crs:OriginalInstanceDigest), 13–76 MB per photo, 551 MB over 15 photos in one folder. This looks like the payload being deflated on the catalog-model queue.

Lightroom Desktop Version Number (Help > System Info)
Lightroom 9.6 x64 [20260923-1659-a32d844] (Sep 23 2026), Camera Raw 18.7 [2743], CR SDK 29.5.0.202509162212_6e7a997. Creative Cloud build (not the Mac App Store copy).
GPU: Apple M5 Pro, Metal; GPU setting "Custom: display only" (the behaviour is the same with full GPU acceleration).
Available physical memory for Lightroom: 49152 MB; Camera Raw virtual memory limit shown as 22528 MB.

OS Version Number
macOS 26.6.2 (25G83). MacBook Pro (Mac17,8), Apple M5 Pro, 48 GB RAM, 18 logical CPUs. Photos on an external APFS SSD over USB4/Thunderbolt.

Camera Model
Canon EOS R5 Mark II, CR3 (45 MP). XMP sidecars plus .acr sidecars written by Lightroom.

Step-by-step Reproduction Instructions
1. Local mode, Lightroom Desktop 9.6, macOS, 48 GB RAM.
2. Take a folder of about 40 CR3 files from an R5 Mark II. Apply Enhance (Denoise) to all of them. On 10–15 of them additionally apply generative remove so the photo becomes "Flattened" (Denoise first, then generative remove). Add a few AI masks and a crop on each. Quit Lightroom.
3. Open Lightroom, Local, open that folder, open the first Enhanced photo in the loupe. Observe: Develop panel greyed out and beachball for 20–40 s; Activity Monitor shows the Lightroom process at ~100–180 % CPU, 17 cores idle, no disk activity.
4. Press the right arrow through the next 10 photos, watching Help > System Info ("Physical memory used by Lightroom", "Camera Raw virtual memory"). Observe: each photo adds 2–3 GB; nothing is released when leaving a photo. With 8 photos (3 Flattened) the process goes from 6 to 24 GB in about 90 s.
5. Zoom to 200 % on a Flattened photo. Observe: memory jumps by ~10–14 GB, then Lightroom drops the renders (photo falls back to the unedited look for a moment, thumbnails pixelate), Camera Raw memory in System Info goes to 0, then the folder is rebuilt and step 3 repeats for every Flattened photo.
6. Double-click to return to the grid, then open any photo again. Observe: same purge and rebuild.

The Expected Result
Opening an already edited photo takes a second or two and does not block the UI on one core while the other 17 idle. Memory for photos no longer displayed is released incrementally; Lightroom does not run to its memory limit and then throw everything away and rebuild the folder.

The Actual Result
20–40 s UI stall per Enhanced/Flattened photo on first open; 2–3 GB retained per photo viewed; purge at ~80 % of the Camera Raw limit (or on returning to the grid) followed by a full rebuild of the folder with the same stalls; one Jetsam kill at 24.2 GB. A 48 GB machine cannot browse a folder with more than about 8 such photos without hitting this loop. Exporting the same 39 photos takes 93 s total, so the render pipeline itself is fast; only interactive viewing takes the single-core path.

Attachments (adobe_report_2026-10-27.zip)
- profiles/: three `sample` captures of the process during the stall (hot thread, nested lua_pcall into CameraRaw deflate), Jetsam report
- logs/process_samples_10s.csv: footprint, malloc, CPU, threads, compressor, swap every ~8 s
- logs/app.log (acr_memory_mb max 20276, app_memory_mb max 35722, last commands purge_memory → renderToDNG), Camera Raw log, lrcc_console.log
- system_info.txt
- REPORT_performance.md with the same text and offsets