Lightroom Classic 15.5: "Add" import is serialized on the main thread — UI freezes ("Not Responding") while CPU, disk and network sit idle
Summary
Importing photos in Add mode (files already local on a fast NVMe volume, no copy/convert) is extremely slow. CPU utilization spikes for 1–2 seconds, then the application goes idle for 5–10+ seconds, repeating in a cycle. During the idle gaps the Lightroom window intermittently reports Not Responding. Per-second process tracing shows the import pipeline is running with a median of 2 active threads while the rest of the machine is idle. All external causes (storage, antivirus, network, background analysis features) have been measured and excluded — details below.
Environment
| Item | Value |
| Lightroom Classic | 15.5 [ 202607291506-b8869fa7 ], Camera Raw 18.5 [ 2673 ] |
| OS | Windows 11 Enterprise, build 11.0.26200 |
| CPU | AMD Ryzen Threadripper PRO 9975WX — 32 cores / 64 logical processors |
| RAM | 256 GB (Lightroom reports 261,500 MB available) |
| GPU | NVIDIA GeForce RTX (32 GB VRAM), driver current |
| Storage | Photos on Samsung SSD 9100 PRO 8 TB (NVMe); catalog on a separate 8 TB NVMe; system on NVMe. No HDD involved. |
| Catalog | Local only — no Lightroom (cloud) sync |
| Import mode | Add (no copy, no DNG conversion). Source files are already on the local NVMe volume before import. |
| Photos | 4800 number of files, RAW format (Canon CR3 and Fujifilm raf), Canon EOS R5 Mark II, Fujifilm GFX 100 II |
| Preview setting at import | 1:1 |
Catalog Settings → Metadata: Address Lookup off, Face Detection off, Assisted Culling off, Duplicate Detection off, auto-write XMP off.
Notably, Lightroom's own System Info reports:
Maximum thread count used by Camera Raw: 5
on a machine with 64 logical processors.
Measurements (per-second process trace, 178 s during import)
A PowerShell sampler recorded CPU, disk I/O and thread states for Lightroom.exe and MsMpEng.exe (Windows Defender) once per second during an Add import (140 samples). Results for Lightroom.exe:
- CPU: median 4.7 %, average 7.8 %, maximum 61.0 % (of the whole 64-LP machine; one fully busy core = 1.56 %). 79 % of all samples were below 6 cores’ worth of CPU.
- Disk: 64 % of samples show ~0 MB/s in both directions. When Lightroom does read, the NVMe delivers instantly — bursts up to 1,694 MB/s at 0.7 ms average response time (Task Manager: 0 % active time on the volume overall). Storage is not the bottleneck.
- Threads: ~460 threads in the process; median 2 threads in Running state between bursts. The visible cycle is: 1–2 s burst (batch read + Camera Raw decode, up to ~35 cores briefly), then 5–60 s with 1–3 active threads doing small catalog/preview writes while everything else waits.
- Antivirus: MsMpEng.exe was flat at 0 % CPU and 0 MB/s for the entire trace — Defender excluded.
The 1-second CSV trace is available on request.
Wait-chain analysis
While the UI showed Not Responding (Resource Monitor: 457 threads, 4 % CPU), Task Manager → Analyze wait chain on Lightroom.exe reported:
"One or more threads of Lightroom.exe are waiting to finish network I/O." (blocked thread ID captured)
Get-NetTCPConnection for the process at that moment showed no external connections in SYN-SENT (nothing timing out toward the internet), but multiple established loopback (127.0.0.1) socket pairs between Lightroom’s own internal components, plus four internal listen ports. Since Windows WCT classifies all socket waits as "network I/O", the blocked main thread is waiting on Lightroom’s own internal loopback IPC, not on the network.
Negative test: network fully disabled
All network adapters were disabled for 2 minutes during an import. No change in import speed or in the burst/stall pattern. Combined with the wait-chain result, this confirms the stall is internal (main-thread serialization / loopback IPC between Lightroom components), not connectivity, licensing endpoints or telemetry.
Expected behavior
Add-mode import of already-local files on NVMe storage should be bounded by metadata read + catalog insert + preview rendering, and should scale with available cores — or at minimum keep the UI thread responsive.
Actual behavior
Import work appears to be orchestrated through (or blocked behind) the main/UI thread: the message pump stalls (Not Responding), a median of 2 threads do the work, Camera Raw is self-capped at 5 threads, and 62 of 64 logical processors plus a 1.7 GB/s NVMe sit idle for most of the import.
Steps to reproduce
- High-core-count Windows machine (here: 64 LPs), catalog and photos on local NVMe, no cloud sync, all background analysis features off.
- Copy a batch of RAW files to a local NVMe folder outside Lightroom.
- Import via Add (no copy, no conversion).
- Observe CPU in Task Manager (burst/stall cycle), the window intermittently Not Responding, and per-process thread activity (median ~2 running threads).
Available on request
- 1-second CSV trace (CPU / read MB/s / write MB/s / thread states, 178 s)
- Screenshots: Task Manager CPU pattern, disk idle during import, wait-chain dialog, System Info
- ProcDump full memory dump taken at a hang window (shared privately with Adobe only)
AdChoices