Lightroom Classic 15.6: about 30 GiB private memory retained after Assisted Culling / similarity stacking (594 CR3s, also in a new catalog)

TAG
@Anshul_Saini

BACKGROUND
I am opening this separate report at Anshul_Saini's request:
https://community.adobe.com/bug-reports-674/p-lrc-v15-5-on-windows-assisted-culling-triggers-crash-and-memory-leaks-1637630#post7772975

The Assisted Culling / similarity-stacking workflow that previously crashed completed without a crash in my initial 15.6 test. This report concerns the remaining high memory usage; it does not establish that the original crash is fixed in all circumstances.

SYSTEM
Lightroom Classic 15.6, build 202609251514-f839cde9
Windows 11 Home, OS build 26300
Intel Core i7-12700F, 12 cores / 20 logical processors
32 GB RAM
NVIDIA GeForce GTX 1650, 4 GB VRAM
NVIDIA driver 32.0.16.1088 (610.88 Studio)
Catalog on the local C: SSD.

CURRENT PERFORMANCE SETTINGS (CAPTURED 2026-10-01)
Use Graphics Processor: Custom
GPU for display: On
GPU for image processing: On
GPU for Export: On
GPU for Preview Generation: Off
Camera Raw cache maximum: 5 GB
Original catalog's automatic catalog-wide Assisted Culling analysis: Off
The GPU/cache settings were captured before and after the new-catalog reproduction, without changing them. I did not separately record every Performance setting during the original 2026-09-30 test.
The new catalog's startup log records AICulling_enableAutoCullingAnalysisForCatalog as <nil>, while the original catalog records false. I initiated analysis manually in the new catalog.

SOURCE IMAGES
The tested source folder contains 594 Canon .CR3 files, 10.637 GiB, without subfolders or other file types.
The exact selection count during the first test was not recorded.
For the new-catalog repeat, all 594 files were imported using Add and used for the fresh culling test.

ORIGINAL OBSERVATION (2026-09-30, MAIN CATALOG)
1. Run Assisted Culling on the folder.
2. Run stacking by visual similarity.
3. The workflow completed without a crash.
4. Lightroom's working set was approximately 15.15 GiB, with 39.59 GiB of private committed memory.
5. During one 15-second sample, working set changed from 15.16 to 15.15 GiB and private committed memory from 39.60 to 39.59 GiB.
6. Close and reopen Lightroom normally.
7. Memory returned to 2.68 GiB working set / 3.31 GiB private committed memory. Culling scores persisted.

INTERPRETATION AND LIMITATIONS
Private committed memory is not physical RAM usage. The 15-second observation and reduction after restart do not prove a leak; caching or delayed release may also explain retention.
No time-series log or Task Manager screenshot was saved during that original high-memory session.
The initial baseline logs collected on 2026-10-01 are from the session AFTER the original restart and cannot be presented as logs from the original high-memory session.
The followup-new-catalog-test logs were captured from the new reproduction BEFORE any restart.
Some Camera Raw logs predate the test. The log manifest records their dates.

FOLLOW-UP TEST
Reproduced on 2026-10-01 in a separate, initially empty local catalog using the same images:
1. Import all 594 CR3 files using Add, not Copy or Move.
2. Start fresh Assisted Culling analysis for those images.
3. Wait for scoring to finish, then run Stack by Visual Similarity.
4. Confirm both operations are finished and leave Lightroom idle for five minutes.
5. Capture live logs, diagnostic report, Performance preferences and Task Manager evidence before restarting.

The retained-memory behavior also occurred in this new catalog. No Lightroom error/crash event was recorded.

Time-series measurements (GiB, sampled approximately every five seconds):
Before culling: 3.35 working set / 3.77 private committed.
Peak during workflow: 22.30 working set / 30.34 private committed.
Immediately after workflow confirmation: 17.25 working set / 30.02 private committed.
After 300.3 seconds idle: 16.88 working set / 30.01 private committed.
Average process CPU during idle: approximately 0.15% across all 20 logical processors.
System committed memory peaked at approximately 98.14% of the commit limit during the workflow.

There was a small reduction in resident memory during idle, but almost no reduction in private committed memory.
The recordings contain 212 samples spanning 12:43:05 to 13:01:53 local time (UTC+03:00).
The console log records AICulling:start / complete at 12:43:49 / 12:54:18, and again at 12:56:00 / 12:56:45.
The second pair followed the similarity-stacking step. The UI also showed "Undo Auto Stack By Visual Similarity" after the workflow.
Fine-grained culling thresholds and stack-similarity settings were not separately recorded.
Source photo filenames, sizes and modification times were unchanged after the test.
After all pre-restart evidence was collected, I relaunched Lightroom normally and returned to the original catalog. Memory was 2.92 GiB working set / 2.62 GiB private committed. This reopened a different catalog, so it is not a same-catalog restart comparison.

ATTACHMENTS
- Task Manager screenshot from the reproduced high-memory session, plus a baseline screenshot.

- Screenshots of Preferences > Performance before and after the test.

The diagnostic ZIP and raw logs may contain local paths, device identifiers, application details and photo filenames. I can provide them privately to Adobe rather than posting them publicly.
 

REQUEST
Is this degree of memory retention expected caching after Assisted Culling / similarity stacking, including in a new catalog, or does it warrant investigation? What further diagnostic data would help distinguish caching from a leak?