Skip to main content
Participant
August 29, 2026
Question

Lightroom Classic 15.5.1: Progressive physical-memory accumulation during Develop navigation with GPU acceleration enabled; memory remains retained while idle

  • August 29, 2026
  • 9 replies
  • 372 views

I've spent a couple of hours researching this thinking it was some other process i was doing and it's causing some memory issues and eventually maxing out my swap memory on my m1 max 64GB Ram macbook pro. Please advise (using Tahoe 26.5.1 (25F80))

 

Title: Lightroom Classic 15.5.1: Progressive physical-memory accumulation during Develop navigation with GPU acceleration enabled; memory remains retained while idle

Summary:
On Lightroom Classic 15.5.1, simply navigating through previously edited RAW photos in Develop, without making any new edits, causes Lightroom's OS-measured physical footprint to increase by several gigabytes per image. In a clean reproduction, Lightroom grew from ~1GB to ~31GB after viewing five images. No material reclamation occurred during a three-minute idle period. The same behavior reproduced on 15.5, where Lightroom reached ~48-51GB and remained at that level for ten minutes idle; quitting and relaunching Lightroom reset the process footprint to ~946MB.

Disabling Use Graphics Processor dramatically changes the behavior: on the same first two images, GPU-enabled Lightroom grew by +13GB and +6GB, while GPU-disabled Lightroom grew by only +1.7GB and +0.6GB. This strongly implicates Lightroom Classic's GPU-accelerated Develop path.

In ordinary editing sessions this progressive footprint growth eventually produces macOS memory compression and multi-gigabyte swapouts, corresponding with severe Lightroom sluggishness/freezing.

Environment:
- Lightroom Classic version: 15.5.1 [202608131348-cab7eed5] (also reproduced on 15.5 [202607291506-b8869fa7] before updating)
- Camera Raw: 18.5.1 [2687]
- macOS: 26.5.1 (25F80)
- Hardware: Apple M1 Max (arm64), 64GB unified memory — Adobe's documented minimum for full GPU acceleration/AI features on Apple Silicon is 16GB; this system has 4x that
- GPU config tested: Custom, with Display/Image Processing/Export all enabled and Preview Generation set to Auto (a valid, Adobe-supported manual configuration — Lightroom's own UI confirmed "Full graphics acceleration is enabled")
- Catalog: ~5.1GB, local SSD, no network/cloud storage involved
- Measurement tools: Lightroom's own Preferences > Performance > System Info panel, and macOS's `footprint` command-line tool (reports phys_footprint, the same physical-memory accounting macOS uses for memory-pressure and jetsam decisions)

Steps to reproduce:
- Launch Lightroom Classic fresh (confirm low baseline memory via Activity Monitor or footprint)
- Open a catalog containing photos with substantial existing, saved Develop-module edit history (prior local retouch/heal work, correction masks — some with Remove/AI-related edits from earlier sessions). Performing a new AI/Remove operation during the reproduction itself is not required
- In the Develop module, navigate to a previously-edited photo, let it render a few seconds
- Navigate to a different previously-edited photo, repeat for 4-5 photos total, viewing only — no new edits
- At each step, check Preferences > Performance > System Info for "Dedicated GPU memory used by Lightroom," and independently check `footprint -p <pid>` for phys_footprint

Expected result:
Memory should remain bounded, or be reclaimed sufficiently, that ordinary Develop navigation does not progressively consume tens of gigabytes of physical memory and drive macOS into compression/swap.

Actual result:
Physical memory footprint climbs steadily across successive images and shows no material reclamation over the idle periods tested, even though the per-image entries in the System Info "Cache1" list do change/rotate as you move between photos. The total physical footprint is not accounted for by what's visible in that panel.

Data — GPU acceleration ON, version 15.5.1, fresh launch:
- Baseline: 194MB GPU-reported / 1.05GB phys_footprint
- Photo 1 (aar05249.ARW): 7.9GB GPU-reported / 14GB phys_footprint (+13GB)
- Photo 2 (aar05189.ARW): 14.2GB GPU-reported / 20GB phys_footprint (+6GB)
- Photo 3 (aar05367.ARW): 19.0GB GPU-reported / 25GB phys_footprint (+5GB)
- Photo 4 (aar05078.ARW): 20.2GB GPU-reported / 27GB phys_footprint (+2GB)
- Photo 5 (aar04996.ARW): 22.9GB GPU-reported / 31GB phys_footprint (+4GB)
- +1 min idle in Library view, no navigation: 31GB (peak 34GB), no change
- +2 min idle: 31GB (peak 34GB), no change
- +3 min idle: 31GB (peak 34GB), no change
- No new edits, exports, or AI operations were performed during this sequence — only viewing already-edited photos

Data — same test on 15.5 (before updating to 15.5.1), same pattern, larger absolute numbers:
- Growth across a comparable 5-6 image sequence (phys_footprint, peak in parentheses): 30GB (31GB) -> 33GB (37GB) -> 42GB (42GB) -> 51GB (51GB)
- After navigation stopped, footprint settled to 48GB (peak 54GB), then held at exactly 48GB for a separately-logged, full 10-minute idle period with zero photos touched
- Quitting and relaunching Lightroom immediately reset phys_footprint from 48GB to 946MB, demonstrating a full quit/relaunch reliably reclaims the memory; no other reclamation action was tested

Data — GPU acceleration OFF (Preferences > Performance > Use Graphics Processor > Off), version 15.5.1, fresh launch, same photos:
- Baseline: 0MB GPU-reported / 912MB phys_footprint
- Photo 1 (aar05249.ARW): 0MB GPU-reported / 2.65GB phys_footprint (+1.7GB)
- Photo 2 (aar05189.ARW): 0MB GPU-reported / 3.25GB phys_footprint (+0.6GB)
- Compare to the same two photos with GPU on: +13GB and +6GB respectively — roughly a 7-10x smaller increase with GPU disabled
- Idle reclamation with GPU disabled was not separately tested, so this speaks only to growth rate, not whether GPU-off allocations are themselves fully reclaimed

Additional context:
- Related but not identical: an existing report describes GPU memory filling during Panorama/HDR merge and not being released until Lightroom is restarted (community.adobe.com/t5/lightroom-classic-discussions/hdr-panorama-merging-ram-not-being-released). Adobe's response there was to ask the reporter to test under 15.5. This report reproduces the same underlying retention pattern via a different trigger — ordinary Develop-module navigation, no Panorama or HDR involved — confirmed still present on 15.5.1
- Adobe's published fixed-issues list for the 15.x line does not mention this Develop/GPU memory-retention behavior as addressed

Why this matters:
This reproduces from ordinary use of the Develop module on hardware well above Adobe's own stated minimum for full GPU/AI feature support. In real editing sessions working through a shoot of dozens to hundreds of photos, this progressive footprint growth has been independently measured (via a custom 1-second-resolution system sampler run over several days of normal use) to correspond with macOS memory compression and eventual multi-gigabyte real disk swapouts, alongside severe application sluggishness — observed on multiple separate occasions, both before and after updating to 15.5.1.

Full minute-by-minute and second-by-second system telemetry covering this entire investigation is available on request.
 

9 replies

Participant
September 24, 2026

I am seeing very substantial progressive memory growth in Lightroom Classic 15.5.1 on Windows 10 with 64 GB RAM.

Using Microsoft Process Explorer, I observed Lightroom.exe Private Bytes increasing during an ordinary Lightroom session approximately as follows:

6 GB → 9 GB → 15.5 GB → 33.9 GB

At one point Lightroom was using approximately 78% CPU, although later CPU dropped to about 5% while Private Bytes remained above 30 GB.

I initially suspected GPU acceleration because Lightroom started this morning with the GPU disabled. However, I restarted Lightroom with Use Graphics Processor explicitly set to OFF and the progressive memory growth still occurred.

I also closed ACDSee Ultimate 2027, which I had recently installed, and restarted Lightroom with ACDSee not running. Lightroom's Private Bytes still climbed rapidly, reaching approximately 10 GB shortly after launch. This therefore does not appear to require ACDSee to be running.

Process Explorer also showed substantial disk-read activity during one episode. Lightroom had its preview database (previews.db and root-pixels.db) open on my dedicated Lightroom preview SSD.

When Lightroom reached approximately 33.9 GB Private Bytes, its Working Set was approximately 9 GB. Closing Lightroom normally immediately released the allocated memory and Lightroom.exe terminated normally.

System:
Windows 10 Pro 22H2
Intel Core i9-10900
64 GB RAM
NVIDIA RTX 2060 6 GB
Lightroom Classic 15.5.1

I can provide further Process Explorer measurements/screenshots or run specific tests if useful.

 

System info: 

Lightroom Classic version: 15.5.1 [ 202608131348-cab7eed5 ]
License: Creative Cloud
Language setting: en
Operating system: Windows 10 - Business Edition
Version: 10.0.19045
Application architecture: x64
System architecture: x64
Logical processor count: 20
Processor speed: 2.8GHz
SqLite Version: 3.36.0
Adobe GSDK Version: 1.4.0.213

CPU Utilisation: 8.0%
Power Source: Plugged In
Built-in memory: 65452.7 MB
Dedicated GPU memory used by Lightroom: 729.9MB / 5945.0MB (12%)
Real memory available to Lightroom: 65452.7 MB
Real memory used by Lightroom: 7909.9 MB (12.0%)
Virtual memory used by Lightroom: 18187.6 MB
GDI objects count: 946
USER objects count: 3868
Process handles count: 3032
Memory cache size: 31.6MB
Internal Camera Raw version: 18.5.1 [ 2687 ]
Maximum thread count used by Camera Raw: 5
Camera Raw SIMD optimization: SSE2,AVX,AVX2
Camera Raw virtual memory: 58MB / 32726MB (0%)
Camera Raw real memory: 61MB / 65452MB (0%)

Cache1: 
NT- RAM:0.0MB, VRAM:0.0MB, Combined:0.0MB

Cache2: 
m:31.6MB, n:0.0MB

U-main: 89.0MB

System DPI setting: 144 DPI (high DPI mode)
Desktop composition enabled: Yes
Standard Preview Size: 3840 pixels
Displays: 1) 3840x2160
Input types: Multitouch: No, Integrated touch: No, Integrated pen: No, External touch: No, External pen: No, Keyboard: No

Graphics Processor Info: 
DirectX: NVIDIA GeForce RTX 2060 (32.0.16.1062)
Init State: GPU for Image Processing supported by default
User Preference: Off
Enable HDR in Library: OFF
GPU for Preview Generation: Off (S3_5)

Application folder: C:\Program Files\Adobe\Adobe Lightroom Classic
Library Path: L:\Lightroom\Lightroom Catalog - Copy-v15.lrcat
Settings Folder: C:\Users\sgpfw\AppData\Roaming\Adobe\Lightroom

Installed Plugins: 
1) AdobeStock
2) DxO OpticsPro 10
3) DxO OpticsPro 10 Importer
4) Flickr
5) HDR Efex Pro 2
6) Negative Lab Pro
7) Topaz Photo (Studio)

Config.lua flags: 
Adapter #1: Vendor : 10de
    Device : 1e89
    Subsystem : 87971043
    Revision : a1
    Video Memory : 5945
Adapter #2: Vendor : 1414
    Device : 8c
    Subsystem : 0
    Revision : 0
    Video Memory : 0
AudioDeviceIOBlockSize: 1024
AudioDeviceName: System Default - Højttalere (Realtek(R) Audio)
AudioDeviceNumberOfChannels: 2
AudioDeviceSampleRate: 48000
Build: LR5x31
Direct2DEnabled: false
GL_ACCUM_ALPHA_BITS: 16
GL_ACCUM_BLUE_BITS: 16
GL_ACCUM_GREEN_BITS: 16
GL_ACCUM_RED_BITS: 16
GL_ALPHA_BITS: 0
GL_BLUE_BITS: 8
GL_DEPTH_BITS: 24
GL_GREEN_BITS: 8
GL_MAX_3D_TEXTURE_SIZE: 16384
GL_MAX_TEXTURE_SIZE: 32768
GL_MAX_TEXTURE_UNITS: 4
GL_MAX_VIEWPORT_DIMS: 32768,32768
GL_RED_BITS: 8
GL_RENDERER: NVIDIA GeForce RTX 2060/PCIe/SSE2
GL_SHADING_LANGUAGE_VERSION: 4.60 NVIDIA
GL_STENCIL_BITS: 8
GL_VENDOR: NVIDIA Corporation
GL_VERSION: 4.6.0 NVIDIA 610.62
GPUDeviceEnabled: false
OGLEnabled: true
GL_EXTENSIONS: GL_AMD_multi_draw_indirect GL_AMD_seamless_cubemap_per_texture GL_AMD_vertex_shader_viewport_index GL_AMD_vertex_shader_layer GL_ARB_arrays_of_arrays GL_ARB_base_instance GL_ARB_bindless_texture GL_ARB_blend_func_extended GL_ARB_buffer_storage GL_ARB_clear_buffer_object GL_ARB_clear_texture GL_ARB_clip_control GL_ARB_color_buffer_float GL_ARB_compatibility GL_ARB_compressed_texture_pixel_storage GL_ARB_conservative_depth GL_ARB_compute_shader GL_ARB_compute_variable_group_size GL_ARB_conditional_render_inverted GL_ARB_copy_buffer GL_ARB_copy_image GL_ARB_cull_distance GL_ARB_debug_output GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_depth_texture GL_ARB_derivative_control GL_ARB_direct_state_access GL_ARB_draw_buffers GL_ARB_draw_buffers_blend GL_ARB_draw_indirect GL_ARB_draw_elements_base_vertex GL_ARB_draw_instanced GL_ARB_enhanced_layouts GL_ARB_ES2_compatibility GL_ARB_ES3_compatibility GL_ARB_ES3_1_compatibility GL_ARB_ES3_2_compatibility GL_ARB_explicit_attrib_location GL_ARB_explicit_uniform_location GL_ARB_fragment_coord_conventions GL_ARB_fragment_layer_viewport GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_fragment_shader_interlock GL_ARB_framebuffer_no_attachments GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_geometry_shader4 GL_ARB_get_program_binary GL_ARB_get_texture_sub_image GL_ARB_gl_spirv GL_ARB_gpu_shader5 GL_ARB_gpu_shader_fp64 GL_ARB_gpu_shader_int64 GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_imaging GL_ARB_indirect_parameters GL_ARB_instanced_arrays GL_ARB_internalformat_query GL_ARB_internalformat_query2 GL_ARB_invalidate_subdata GL_ARB_map_buffer_alignment GL_ARB_map_buffer_range GL_ARB_multi_bind GL_ARB_multi_draw_indirect GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_occlusion_query2 GL_ARB_parallel_shader_compile GL_ARB_pipeline_statistics_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_polygon_offset_clamp GL_ARB_post_depth_coverage GL_ARB_program_interface_query GL_ARB_provoking_vertex GL_ARB_query_buffer_object GL_ARB_robust_buffer_access_behavior GL_ARB_robustness GL_ARB_sample_locations GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_seamless_cube_map GL_ARB_seamless_cubemap_per_texture GL_ARB_separate_shader_objects GL_ARB_shader_atomic_counter_ops GL_ARB_shader_atomic_counters GL_ARB_shader_ballot GL_ARB_shader_bit_encoding GL_ARB_shader_clock GL_EXT_shader_realtime_clock GL_ARB_shader_draw_parameters GL_ARB_shader_group_vote GL_ARB_shader_image_load_store GL_ARB_shader_image_size GL_ARB_shader_objects GL_ARB_shader_precision GL_ARB_shader_storage_buffer_object GL_ARB_shader_subroutine GL_ARB_shader_texture_image_samples GL_ARB_shader_texture_lod GL_ARB_shading_language_100 GL_ARB_shader_viewport_layer_array GL_ARB_shading_language_420pack GL_ARB_shading_language_include GL_ARB_shading_language_packing GL_ARB_shadow GL_ARB_sparse_buffer GL_ARB_sparse_texture GL_ARB_sparse_texture2 GL_ARB_sparse_texture_clamp GL_ARB_spirv_extensions GL_ARB_stencil_texturing GL_ARB_sync GL_ARB_tessellation_shader GL_ARB_texture_barrier GL_ARB_texture_border_clamp GL_ARB_texture_buffer_object GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_buffer_range GL_ARB_texture_compression GL_ARB_texture_compression_bptc GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map GL_ARB_texture_cube_map_array GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_filter_anisotropic GL_ARB_texture_filter_minmax GL_ARB_texture_float GL_ARB_texture_gather GL_ARB_texture_mirror_clamp_to_edge GL_ARB_texture_mirrored_repeat GL_ARB_texture_multisample GL_ARB_texture_non_power_of_two GL_ARB_texture_query_levels GL_ARB_texture_query_lod GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_texture_rgb10_a2ui GL_ARB_texture_stencil8 GL_ARB_texture_storage GL_ARB_texture_storage_multisample GL_ARB_texture_swizzle GL_ARB_texture_view GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_transform_feedback_instanced GL_ARB_transform_feedback_overflow_query GL_ARB_transpose_matrix GL_ARB_uniform_buffer_object GL_ARB_vertex_array_bgra GL_ARB_vertex_array_object GL_ARB_vertex_attrib_64bit GL_ARB_vertex_attrib_binding GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_vertex_type_10f_11f_11f_rev GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_ARB_window_pos GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_bindable_uniform GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_depth_bounds_test GL_EXT_direct_state_access GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXTX_framebuffer_mixed_formats GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_multi_draw_arrays GL_EXT_multiview_texture_multisample GL_EXT_multiview_timer_query GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_polygon_offset_clamp GL_EXT_post_depth_coverage GL_EXT_provoking_vertex GL_EXT_raster_multisample GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_shader_objects GL_EXT_separate_specular_color GL_EXT_shader_image_load_formatted GL_EXT_shader_image_load_store GL_EXT_shader_integer_mix GL_EXT_shadow_funcs GL_EXT_sparse_texture2 GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_array GL_EXT_texture_buffer_object GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_latc GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_filter_minmax GL_EXT_texture_integer GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_shadow_lod GL_EXT_texture_shared_exponent GL_EXT_texture_sRGB GL_EXT_texture_sRGB_R8 GL_EXT_texture_sRGB_decode GL_EXT_texture_storage GL_EXT_texture_swizzle GL_EXT_timer_query GL_EXT_transform_feedback2 GL_EXT_vertex_array GL_EXT_vertex_array_bgra GL_EXT_vertex_attrib_64bit GL_EXT_window_rectangles GL_EXT_import_sync_object GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KHR_context_flush_control GL_KHR_debug GL_EXT_memory_object GL_EXT_memory_object_win32 GL_NV_memory_object_sparse GL_EXT_win32_keyed_mutex GL_KHR_parallel_shader_compile GL_KHR_no_error GL_KHR_robust_buffer_access_behavior GL_KHR_robustness GL_EXT_semaphore GL_EXT_semaphore_win32 GL_NV_timeline_semaphore GL_KHR_shader_subgroup GL_KTX_buffer_region GL_NV_alpha_to_coverage_dither_control GL_NV_bindless_multi_draw_indirect GL_NV_bindless_multi_draw_indirect_count GL_NV_bindless_texture GL_NV_blend_equation_advanced GL_NV_blend_equation_advanced_coherent GL_NVX_blend_equation_advanced_multi_draw_buffers GL_NV_blend_minmax_factor GL_NV_blend_square GL_NV_clip_space_w_scaling GL_NV_command_list GL_NV_compute_program5 GL_NV_compute_shader_derivatives GL_NV_conditional_render GL_NV_conservative_raster GL_NV_conservative_raster_dilate GL_NV_conservative_raster_pre_snap GL_NV_conservative_raster_pre_snap_triangles GL_NV_conservative_raster_underestimation GL_NV_copy_depth_to_color GL_NV_copy_image GL_NV_depth_buffer_float GL_NV_depth_clamp GL_NV_draw_texture GL_NV_draw_vulkan_image GL_NV_ES1_1_compatibility GL_NV_ES3_1_compatibility GL_NV_explicit_multisample GL_NV_feature_query GL_NV_fence GL_NV_fill_rectangle GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_coverage_to_color GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_fragment_shader_barycentric GL_NV_fragment_shader_interlock GL_NV_framebuffer_mixed_samples GL_NV_framebuffer_multisample_coverage GL_NV_geometry_shader4 GL_NV_geometry_shader_passthrough GL_NV_gpu_program4 GL_NV_internalformat_sample_query GL_NV_gpu_program4_1 GL_NV_gpu_program5 GL_NV_gpu_program5_mem_extended GL_NV_gpu_program_fp64 GL_NV_gpu_program_multiview GL_NV_gpu_shader5 GL_NV_half_float GL_NV_light_max_exponent GL_NV_memory_attachment GL_NV_mesh_shader GL_NV_multisample_coverage GL_NV_multisample_filter_hint GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_parameter_buffer_object GL_NV_parameter_buffer_object2 GL_NV_path_rendering GL_NV_path_rendering_shared_edge GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_query_resource GL_NV_query_resource_tag GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_representative_fragment_test GL_NV_sample_locations GL_NV_sample_mask_override_coverage GL_NV_scissor_exclusive GL_NV_shader_atomic_counters GL_NV_shader_atomic_float GL_NV_shader_atomic_float64 GL_NV_shader_atomic_fp16_vector GL_NV_shader_atomic_int64 GL_NV_shader_buffer_load GL_NV_shader_storage_buffer_object GL_NV_shader_subgroup_partitioned GL_NV_shader_texture_footprint GL_NV_shading_rate_image GL_NV_stereo_view_rendering GL_NV_texgen_reflection GL_NV_texture_barrier GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_multisample GL_NV_texture_rectangle GL_NV_texture_rectangle_compressed GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_texture_shader3 GL_NV_transform_feedback GL_NV_transform_feedback2 GL_NV_uniform_buffer_unified_memory GL_NV_uniform_buffer_std430_layout GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_attrib_integer_64bit GL_NV_vertex_buffer_unified_memory GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_NV_viewport_array2 GL_NV_viewport_swizzle GL_NVX_conditional_render GL_NVX_linked_gpu_multicast GL_NV_gpu_multicast GL_NVX_gpu_multicast2 GL_NVX_progress_fence GL_NVX_gpu_memory_info GL_NVX_multigpu_info GL_NVX_nvenc_interop GL_NV_shader_thread_group GL_NV_shader_thread_shuffle GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent GL_OVR_multiview GL_OVR_multiview2 GL_SGIS_generate_mipmap GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_slice_accum GL_WIN_swap_hint WGL_EXT_swap_control 

alexskunz
Inspiring
September 16, 2026

Hello ​@Anshul_Saini here are my numbers (rounded) from LrC 15.5.1. The memory usage is from macOS “Activity Monitor” on the “Memory” tab.

  • Launch to Library Grid & set filters: 2.1 GB
  • Switch to Develop, 1st photo: 14.7 GB
  • After loading 2nd photo: 18.5 GB
  • After loading 3rd photo: 20.5 GB
  • After loading 4th photo: 20.8 GB
  • After loading 5th photo: 23.4 GB
  • Back to grid: 21.9 GB (capture system info, immediately)
  • After idle for ~5 minutes: 20.7 GB (capture system info again)

I will try and perform the extended test with minimally developed photos next.

In another, less organized approach and just while working on photos in the Develop module, I have written down some more numbers:

  • (22:00) 47.5 GB memory usage, while working
  • (22:30) 42.9 GB memory usage, before minimizing (bedtime!)
  • (06:30) 41.5 GB memory usage, after minimized/idle for 8 hours

In other words, while idling for 8 hours, LrC only released 1.4 GB of memory.

In the meantime I had also flagged down ​@Vikash Mehta through another channel.

Hope to help,

Alex.

Anshul_Saini
Community Manager
Community Manager
September 17, 2026

@alexskunz, thank you for the detailed measurements and for including the System Info from both runs. Your numbers continue to show the same pattern: Lightroom’s memory usage rises substantially while moving through previously edited photos in Develop, and only part of that memory is released after returning to Library and waiting several minutes. Your additional observation of 47.5 GB > 41.5 GB after 8 hours of idle is also an important data point.

I also noticed that you’re still on Camera Raw 18.5.1. Could you please update and test with 18.6? Once it's updated, please repeat the shortened 5-photo test with the same files.

The other test I’d still like to see is the comparison with five RAW files that have only basic Develop adjustments and no masks, Remove, Denoise, Lens Blur, or other AI-based edits. You don’t need to repeat the longer investigation; record the memory usage before and after viewing those five images, and after a few minutes of idle time.

That comparison should help us determine whether the memory growth is specifically associated with previously edited images using the AI feature or AI-masked images, or whether it also occurs with more basic Develop content.

Thank you again for taking the time to capture these measurements. The additional data from your M2 Max system is very helpful.

Best
Anshul Saini

alexskunz
Inspiring
September 17, 2026

Hi again ​@Anshul_Saini I have ACR 18.6 installed but that’s not the version that’s integrated with LrC 15.5.1 as far as I can see.

Anshul_Saini
Community Manager
Community Manager
September 15, 2026

Hi @quirky_projectf12e and @alexskunz,

Thank you for the exceptionally detailed testing and measurements. Before I consolidate this for the product team, I’d like to establish the behavior on the latest available components.

Please update to Camera Raw 18.6 and check whether it appears under LrC Help > System Info. If macOS 26.7 is available for your Mac, please update to that as well and repeat the same test.

You don’t need to repeat the entire investigation. A shorter controlled test would be enough:

1. Quit and relaunch Lightroom Classic.

2. Confirm GPU acceleration is enabled using the same settings as your original test.

3. Navigate through the same 5 previously edited images in Develop without making any new edits.

4. Record Lightroom’s physical-memory usage after each image.

5. Stop navigating and leave Lightroom idle for about 5 minutes, then record the memory usage again.

Please also capture Help > System Info > Copy immediately after the test and paste it here. That will give us the exact Lightroom Classic, Camera Raw, macOS, and GPU configuration corresponding to the new measurements.

One additional comparison would be particularly valuable. Since you mentioned that some of these images contain existing masks/Remove/AI-related edits, could you repeat the short test with 5 otherwise comparable RAW files that have only basic Develop adjustments and no masks, Remove edits, Denoise, Lens Blur, or other AI edits?

If memory remains relatively bounded with those files but grows substantially when walking through the previously AI or mask-edited files, that gives us a much narrower reproduction case. If both sets exhibit the same accumulation, that’s equally useful.

There’s no need to reset preferences, rebuild previews, reinstall Lightroom Classic, or perform other general troubleshooting at this point. You’ve already provided enough evidence that I’d rather keep the test environment controlled.

@alexskunz, since you’ve confirmed the behavior on an M2 Max as well, please run the same shortened test and include your System Info if possible. Having matching results from M1 Max and M2 Max systems would be particularly useful.

Once we have the results from the current Lightroom Classic/Camera Raw combination, I’ll consolidate the reproduction details for the product team.

Thanks again for the very thorough report.

Best,

Anshul Saini

alexskunz
Inspiring
September 17, 2026

​@Anshul_Saini and here are my numbers from a test with minimally developed files. I had overlooked in your requirements that you said “no AI Denoise” so I accidentally included that, but none of the other things you asked to be excluded.

  • Launch into Library Grid 1.3 GB
  • 1st photo 5.9 GB (Auto Toning)
  • 2nd photo 8.7 GB (Adaptive Profile)
  • 3rd photo 12.5 GB (AI Denoise)
  • 4th photo 14.3 GB (Basic panel manual adjustments)
  • 5th photo 14.7 GB (Auto Toning + Vignetting and captured System Info)
  • After 5 minutes 13.1 GB (captured System Info again)

Hope to help

Alexander.

 

Anshul_Saini
Community Manager
Community Manager
September 23, 2026

Thank you, @alexskunz, this comparison is very helpful.

Even with this much more lightly edited set, memory usage increased from 1.3 GB at launch to 14.7 GB after five images, then decreased only to 13.1 GB after five minutes of idle.

That’s a useful comparison with your earlier test. The accumulation is more pronounced with the previously heavily edited images, but it isn’t limited to images containing masks/Remove or other complex AI edits.

I have enough info from these tests now, so there’s no need to run additional variations for me at this point.

Thanks again for taking the time to collect such detailed measurements. I will take this forward to the product and engineering team.

Best,
Anshul Saini

Participant
September 5, 2026

I've spent a couple of hours researching this thinking it was some other process i was doing and it's causing some memory issues and eventually maxing out my swap memory on my m1 max 64GB Ram macbook pro. Please advise (using Tahoe 26.5.1 (25F80))

 

Title: Lightroom Classic 15.5.1: Progressive physical-memory accumulation during Develop navigation with GPU acceleration enabled; memory remains retained while idle

Summary:
On Lightroom Classic 15.5.1, simply navigating through previously edited RAW photos in Develop, without making any new edits, causes Lightroom's OS-measured physical footprint to increase by several gigabytes per image. In a clean reproduction, Lightroom grew from ~1GB to ~31GB after viewing five images. No material reclamation occurred during a three-minute idle period. The same behavior reproduced on 15.5, where Lightroom reached ~48-51GB and remained at that level for ten minutes idle; quitting and relaunching Lightroom reset the process footprint to ~946MB.

Disabling Use Graphics Processor dramatically changes the behavior: on the same first two images, GPU-enabled Lightroom grew by +13GB and +6GB, while GPU-disabled Lightroom grew by only +1.7GB and +0.6GB. This strongly implicates Lightroom Classic's GPU-accelerated Develop path.

In ordinary editing sessions this progressive footprint growth eventually produces macOS memory compression and multi-gigabyte swapouts, corresponding with severe Lightroom sluggishness/freezing.

Environment:
- Lightroom Classic version: 15.5.1 [202608131348-cab7eed5] (also reproduced on 15.5 [202607291506-b8869fa7] before updating)
- Camera Raw: 18.5.1 [2687]
- macOS: 26.5.1 (25F80)
- Hardware: Apple M1 Max (arm64), 64GB unified memory — Adobe's documented minimum for full GPU acceleration/AI features on Apple Silicon is 16GB; this system has 4x that
- GPU config tested: Custom, with Display/Image Processing/Export all enabled and Preview Generation set to Auto (a valid, Adobe-supported manual configuration — Lightroom's own UI confirmed "Full graphics acceleration is enabled")
- Catalog: ~5.1GB, local SSD, no network/cloud storage involved
- Measurement tools: Lightroom's own Preferences > Performance > System Info panel, and macOS's `footprint` command-line tool (reports phys_footprint, the same physical-memory accounting macOS uses for memory-pressure and jetsam decisions)

Steps to reproduce:
- Launch Lightroom Classic fresh (confirm low baseline memory via Activity Monitor or footprint)
- Open a catalog containing photos with substantial existing, saved Develop-module edit history (prior local retouch/heal work, correction masks — some with Remove/AI-related edits from earlier sessions). Performing a new AI/Remove operation during the reproduction itself is not required
- In the Develop module, navigate to a previously-edited photo, let it render a few seconds
- Navigate to a different previously-edited photo, repeat for 4-5 photos total, viewing only — no new edits
- At each step, check Preferences > Performance > System Info for "Dedicated GPU memory used by Lightroom," and independently check `footprint -p <pid>` for phys_footprint

Expected result:
Memory should remain bounded, or be reclaimed sufficiently, that ordinary Develop navigation does not progressively consume tens of gigabytes of physical memory and drive macOS into compression/swap.

Actual result:
Physical memory footprint climbs steadily across successive images and shows no material reclamation over the idle periods tested, even though the per-image entries in the System Info "Cache1" list do change/rotate as you move between photos. The total physical footprint is not accounted for by what's visible in that panel.

Data — GPU acceleration ON, version 15.5.1, fresh launch:
- Baseline: 194MB GPU-reported / 1.05GB phys_footprint
- Photo 1 (aar05249.ARW): 7.9GB GPU-reported / 14GB phys_footprint (+13GB)
- Photo 2 (aar05189.ARW): 14.2GB GPU-reported / 20GB phys_footprint (+6GB)
- Photo 3 (aar05367.ARW): 19.0GB GPU-reported / 25GB phys_footprint (+5GB)
- Photo 4 (aar05078.ARW): 20.2GB GPU-reported / 27GB phys_footprint (+2GB)
- Photo 5 (aar04996.ARW): 22.9GB GPU-reported / 31GB phys_footprint (+4GB)
- +1 min idle in Library view, no navigation: 31GB (peak 34GB), no change
- +2 min idle: 31GB (peak 34GB), no change
- +3 min idle: 31GB (peak 34GB), no change
- No new edits, exports, or AI operations were performed during this sequence — only viewing already-edited photos

Data — same test on 15.5 (before updating to 15.5.1), same pattern, larger absolute numbers:
- Growth across a comparable 5-6 image sequence (phys_footprint, peak in parentheses): 30GB (31GB) -> 33GB (37GB) -> 42GB (42GB) -> 51GB (51GB)
- After navigation stopped, footprint settled to 48GB (peak 54GB), then held at exactly 48GB for a separately-logged, full 10-minute idle period with zero photos touched
- Quitting and relaunching Lightroom immediately reset phys_footprint from 48GB to 946MB, demonstrating a full quit/relaunch reliably reclaims the memory; no other reclamation action was tested

Data — GPU acceleration OFF (Preferences > Performance > Use Graphics Processor > Off), version 15.5.1, fresh launch, same photos:
- Baseline: 0MB GPU-reported / 912MB phys_footprint
- Photo 1 (aar05249.ARW): 0MB GPU-reported / 2.65GB phys_footprint (+1.7GB)
- Photo 2 (aar05189.ARW): 0MB GPU-reported / 3.25GB phys_footprint (+0.6GB)
- Compare to the same two photos with GPU on: +13GB and +6GB respectively — roughly a 7-10x smaller increase with GPU disabled
- Idle reclamation with GPU disabled was not separately tested, so this speaks only to growth rate, not whether GPU-off allocations are themselves fully reclaimed

Additional context:
- Related but not identical: an existing report describes GPU memory filling during Panorama/HDR merge and not being released until Lightroom is restarted (community.adobe.com/t5/lightroom-classic-discussions/hdr-panorama-merging-ram-not-being-released). Adobe's response there was to ask the reporter to test under 15.5. This report reproduces the same underlying retention pattern via a different trigger — ordinary Develop-module navigation, no Panorama or HDR involved — confirmed still present on 15.5.1
- Adobe's published fixed-issues list for the 15.x line does not mention this Develop/GPU memory-retention behavior as addressed

Why this matters:
This reproduces from ordinary use of the Develop module on hardware well above Adobe's own stated minimum for full GPU/AI feature support. In real editing sessions working through a shoot of dozens to hundreds of photos, this progressive footprint growth has been independently measured (via a custom 1-second-resolution system sampler run over several days of normal use) to correspond with macOS memory compression and eventual multi-gigabyte real disk swapouts, alongside severe application sluggishness — observed on multiple separate occasions, both before and after updating to 15.5.1.

Full minute-by-minute and second-by-second system telemetry covering this entire investigation is available on request.

alexskunz
Inspiring
August 29, 2026

Confirmed on an M2 Max machine on Tahoe 26.6.2