Lightroom CC 2015.10 - Poor Performance

  • 42
  • Problem
  • Updated 2 years ago
  • In Progress
  • (Edited)
This issue collects information passed between myself and the Adobe care team on twitter, who as of April 21st recommended that I make a post here so that the development team could track it.

Starting off with the most up to date system info post:
https://pastebin.com/ngEf5L9y


The summary of the problem is basically laggy / insufferably slow performance issues with LR CC running on a system as follows:
  • i7 4790k @ 4Ghz
  • 32Gb RAM
  • SSD Catalog
  • 2x HGST 5Tb RAID 1 image host drives
  • nVidia 970 GTX 
  • 2560 x 1440 display, LR in Single Display mode only
  • Windows 10 Pro 64bit
Issues such as laggy brushes, 6-10 second wait times when navigating between images, laggy UI interactions, colour shifting and screen blackout behaviours. Screen updates when moving sliders in the develop module can take several seconds to display, and don't even think about using the program in any capacity if an export or import is underway. Multitasking is so passé ;)

I have been engaged with Adobe on this issue for several months, during which time I have kept my display drivers and lightroom up to date.

Performance *HAS* improved slightly since 6.10
but is still not at a point where it is comfortable to smoothly work. Every operation has a lag / UI update that just makes the whole experience jarring. The memory leak that would send LR to its knees was indeed resolved with 6.10, so performance no longer degrades as rapidly over time as it used to, however baseline performance is still not what I'd expect and is certainly not comfortable to work with. Editing in Lightroom is a headache to be dreaded right now, so much so that I've been putting off jobs that I really shouldn't be.

Video 1

https://www.youtube.com/watch?v=Ymh7o9H9wD4

This initial video opened up the dialog with Adobe, and was recorded on 6.8. This is the best performance I ever see from LR as it was freshly loaded up and hadn't been subject to the memory leak in versions < 6.10 . I'm currently regenerating the 1:1 previews on the images in the video to see if the cache was corrupted or something. It's taken 2 hours so far, and it's at 58%. (700 images). In another 2 hours I will be able to say.

(Though I'm not sure 4 hours rendering time is in any way acceptable for 700 images. I'm fairly confident I can render video quicker... :D )


Video 2

https://youtu.be/_e1xTbA3L94

I've produced another video that shows the GPU accel colour shift and screen blackout. This time LR had been open for a few hours, so it's the absolute worst case performance. Running on 6.8 / 6.9 as 6.10 had not yet been released

Video 3

https://www.youtube.com/watch?v=22LgfhKskJA&feature=youtu.be

Another video, this time with some diagnostic information onscreen. It's a long video as I was discussing with a reddit group ideas on how to improve performance. Skip through and you'll find CPU readouts, HDD benchmarks and some other stuff. This was recorded during a 1:1 preview generation session, which took 3 hours for 1000 images.

I've had lightroom open long enough to import 286 images and generate 1:1 previews for them. Performance is still just as bad as in the recorded videos. I'll leave it open and idling overnight to see if it leaks any memory, but honestly the concept of editing even this tiny set of ~300 images is enough to give me a headache.

Face tagging, geotagging, and all other extraneous gubbins turned off from day 1. 1:1 and Smart previews. 90% CPU over 4 cores, but no account given, seemingly, to people trying to use LR while an import is in progress. Its borderline unusable as it is (As I demonstrated in my videos) but during import - no chance. I normally leave it on overnight importing images, but this was a rush job. Rush. Hah.



At this point I was tempted to revert back to 5.7 as , although not exactly a greased sow in terms of performance, it is certainly less cumbersome than CC.
Photo of Denyer Ec

Denyer Ec

  • 55 Posts
  • 43 Reply Likes
  • Frustrated, stressed

Posted 2 years ago

  • 42
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 5994 Posts
  • 1320 Reply Likes
Denyer, 

I updated the title of your thread from CC2017 (which doesn't exist) to CC2015.10.

No where in your text description (I haven't looked at your videos yet) do you mention whether going to Preferences>Performance and unchecking the GPU box improves laggy brushes and sliders. Does it?

Also, with whom at Adobe have you engaged so far and how was that facilitated?  Forum? Social Media? Direct contact?
Photo of Melissa Rios

Melissa Rios, Lightroom Support Product Manager

  • 104 Posts
  • 25 Reply Likes
Hey Rikk, he's been communicating with me over @AdobeCare DM. I'll forward you his conversation since it might include more information.
(Edited)
Photo of Denyer Ec

Denyer Ec

  • 55 Posts
  • 43 Reply Likes
Aye, somewhere in the rather lengthy video 2 I enable/disable GPU Acceleration, as this is a summary of the dialog I've had with Melissa (Hey!) there might be some omissions as I was editing a lengthy twitter back-and-forth. I'll amend that now.
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 5994 Posts
  • 1320 Reply Likes
Got the info from you, Melissa. Thanks.
Photo of Art M.

Art M.

  • 88 Posts
  • 18 Reply Likes
Rikk and Melissa. Would you please level with us. What has gone wrong since version 5.7? Something bad happened in the transition to version 6 and cloud. Personally. I never use the cloud features and it looks like you all did a major rewrite to make it work with cloud, and something went wrong in the rewrite. Was there a major change in development team? Change in development tools?

Why did Lightroom performance in D mode fall off a cliff. I often find myself watching a spinning ball because I did a small clone. And why are most versions so buggy?

The one CLUE that I can give you is that D mode gets really slow in an image after I have made a few edits. The first edit is pretty fast but after a few edits it bogs down severely. (Whether GPU is on or off. I did increase the cache and I leave 100 gig open on SSD).

With latest version sometimes I move a basic slider and there is no effect. It happens randomly. Only a handful of times so far. I dont see any pattern yet.

MacBook Pro 2015 13". I7. 16gig memory.

Is Adobe management aware that all is not well here?
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 5994 Posts
  • 1320 Reply Likes
Art, 

We are being level.

In my personal non-Adobe environments (namely Win 10 Desktop and Mac OSx 10.12.4) Lightroom runs smoothly and quickly.  It is as fast or faster than 5.7.1 in my studio environment even considering I was using a Canon 5d Mark II previously and recently upgraded to a Mark IV with much larger files.  My 2012 MacbookPro runs Lightroom quite zippy on modest specs even when tethering for three days straight!  

Many users are reporting better performance. Some users are reporting poor performance. We can acknowledge both of those. 

The problem with sites like this and other support sites is that there aren't droves of people who come in special just to say "Wow this is working great." Those people continue to work and are blissfully unaware that small groups of users are experiencing issues. Users only come here when they have a problem and the self-selective bias makes things appear more widespread than they really are.  

We are working with users who are having problems with performance to determine where Lightroom's bottlenecks  are the culprit and where individual system configurations need to be adjusted and, in some cases, fixed. 

Art, we are happy to work with you to see if we can resolve Lightroom's poor performance with your system. It will require much more information from you. Would you like to participate?

As to your final question: Adobe Lightroom Management and follows posts in this forum.  Occasionally, they will respond on a thread. 
Photo of Art M.

Art M.

  • 88 Posts
  • 18 Reply Likes
Thanks for the rapid response. I feel like there is a general consensus in the user community about Lightroom problems since the introduction of CC - NOT just here in these forums - but I do realize its hard to judge in forums for the reason you cite. What would I do next to get my system debugged?
Photo of Mihael Tominšek

Mihael Tominšek

  • 37 Posts
  • 31 Reply Likes
Wow. That is something I like to hear. 
I would bring my PC on foot to you center if that helped. Yes we would like to participate... Anything...

I can just say my experience with Premiere where exactly same PC (same installation) is working SLOW with CC2015 and FAST with CC2017. Obviosly Adobe did something that LAG gone. I hope Lr will once be fast too. 
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 5994 Posts
  • 1320 Reply Likes
@Art M. 

The first thing we need is a complete - detailed description of your system. 
Next we need a complete, detailed description of your Lightroom catalog and how the bits are arrayed across your various storage devices./
Lastly, we need specific operations with elapsed times for those operations. 

Those three items allow us to: find, prepare, and perform on a test system to see if your behavior is typical for what we normally see or if it is substantially longer. Based upon that we can make a judgement as to bug, hardware, or system specific configuration issues ( or any combination) are in play. 
Photo of Mihael Tominšek

Mihael Tominšek

  • 37 Posts
  • 31 Reply Likes
I'm on it... where to post and what to post regarding my system/usage (publicly here?)? 
I'm even prepared to erase one computer and test on clean install. 

... but apart from excessive lagginess here and there (usually after new update), the Lr never was fast... or for a long time. A lot of hardware / software changes during the years. The brush lag is know for last few versions...
Photo of Mike S

Mike S

  • 38 Posts
  • 13 Reply Likes
Rikk,
I've been following these threads, and have been doing my own testing.  I may have data that can help.
  • I created a new catalog, with 40 raw images from an Olympus E-M1.  The images are stored on my D: drive, a WD 750GB hard drive.  The catalog is on my C: drive, a 256GB SSD.
  • I compared performance of versions 2015.4 and 2015.10.  I've run 2015.4 since it came out, and its been fast and stable.
My test procedure:
  • Open Lightroom, and allow memory usage to stabilize.  GPU acceleration turned off.  Go to Develop module. 
  • Use arrow key to move right through 10 images, then move back left through the same 10, returning to the original shot.  This simply tests how quickly the Develop module can load and display the same images.
  • For 20 images: apply a preset (highlights to 0, shadows to 100, clarity to 20, camera profile 'Natural').  Then 'Reset' image.  Move to the next image.  Take split times after 5, 10, 15, and 20 images.
Results:
Moving through 10 images right, then left:  2015.4 = 23s, 2015.10 = 33s
Develop 20 images.  Splits for each set of 5:
      2015.4 =   22s, 24s, 22s, 21s
      2015.10 = 39s, 63s, 87s, 123s

I repeated the 2015.10 tests twice (restarted system in between), and got virtually identical results.  The fact that 2015.10 is noticeably slower can be seen in the first 5 images as well as the simple movement test.  The steady performance degradation is obvious too.  By the end of the 20 images, Lightroom was basically unusable and had to be restarted.

Memory utilization on my 16GB RAM system was below 50% throughout the testing.

I haven't tested all the intermediate versions between 15.4 and 15.10 because I'm hoping this is enough to get your own systems set up to duplicate the problem.

The only other data point I can add is that you fixed this once:  this behavior existed in Lightroom version 5, but went away when version 6 (now 2015.x under the CC naming) came out.  Version 6/2015 stayed fast through update 4, then broke somewhere between update 5 and now.

Let me know what else I can provide.  System info is pasted below:
Lightroom version: CC 2015.10 [ 1111918 ]License: Creative Cloud
Operating system: Windows 7 
Version: 6.1
Application architecture: x64
System architecture: x64
Logical processor count: 8
Processor speed: 2.6 GHz
Built-in memory: 16311.1 MB
Real memory available to Lightroom: 16311.1 MB
Real memory used by Lightroom: 1364.3 MB (8.3%)
Virtual memory used by Lightroom: 1515.9 MB
GDI objects count: 805
USER objects count: 2264
Process handles count: 1323
Memory cache size: 897.2MB / 3821.7MB (23.5%)
Maximum thread count used by Camera Raw: 8
Camera Raw SIMD optimization: SSE2,AVX,AVX2
Camera Raw virtual memory: 841MB / 8155MB (10%)
System DPI setting: 120 DPI
Desktop composition enabled: Yes
Displays: 1) 1920x1200, 2) 1920x1080
Input types: Multitouch: No, Integrated touch: No, Integrated pen: No, External touch: No, External pen: No, Keyboard: No

Graphics Processor Info: 
GeForce GTX 780M/PCIe/SSE2

Check OpenGL support: Passed
Vendor: NVIDIA Corporation
Version: 3.3.0 NVIDIA 372.90
Renderer: GeForce GTX 780M/PCIe/SSE2
LanguageVersion: 3.30 NVIDIA via Cg compiler

Application folder: C:\Program Files\Adobe\Adobe Lightroom
Library Path: C:\Lightroom Catalogs\Test Cat\Test Cat.lrcat
Settings Folder: C:\Users\Mike\AppData\Roaming\Adobe\Lightroom

Installed Plugins: 
1) AdobeStock
2) ColorChecker Passport
3) HDR Efex Pro 2
4) Helicon Focus Export
5) Merge to 32-bit
6) ON1 Effects Standalone 10

Config.lua flags: None

Adapter #1: Vendor : 10de
Device : 119f
Subsystem : 5ae1028
Revision : a1
Video Memory : 4026

AudioDeviceIOBlockSize: 1024
AudioDeviceName: Speakers (Realtek High Definition Audio)
AudioDeviceNumberOfChannels: 2
AudioDeviceSampleRate: 48000
Build: LR5x8
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: 2048
GL_MAX_TEXTURE_SIZE: 16384
GL_MAX_TEXTURE_UNITS: 4
GL_MAX_VIEWPORT_DIMS: 16384,16384
GL_RED_BITS: 8
GL_RENDERER: GeForce GTX 780M/PCIe/SSE2
GL_SHADING_LANGUAGE_VERSION: 4.50 NVIDIA
GL_STENCIL_BITS: 8
GL_VENDOR: NVIDIA Corporation
GL_VERSION: 4.5.0 NVIDIA 372.90
GPUDeviceEnabled: false
OGLEnabled: true
GL_EXTENSIONS: GL_AMD_multi_draw_indirect GL_AMD_seamless_cubemap_per_texture 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_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_program_interface_query GL_ARB_provoking_vertex GL_ARB_query_buffer_object GL_ARB_robust_buffer_access_behavior GL_ARB_robustness 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_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_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_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_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_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_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_shader_objects GL_EXT_separate_specular_color GL_EXT_shader_image_load_store GL_EXT_shader_integer_mix GL_EXT_shadow_funcs 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_integer GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_shared_exponent GL_EXT_texture_sRGB 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_KHR_no_error GL_KHR_robust_buffer_access_behavior GL_KHR_robustness 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_square GL_NV_command_list GL_NV_compute_program5 GL_NV_conditional_render 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_fence GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_framebuffer_multisample_coverage GL_NV_geometry_shader4 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_shader5 GL_NV_half_float GL_NV_light_max_exponent 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_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_shader_atomic_counters GL_NV_shader_atomic_float GL_NV_shader_buffer_load GL_NV_shader_storage_buffer_object 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_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_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_NVX_conditional_render 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_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 
(Edited)
Photo of Mihael Tominšek

Mihael Tominšek

  • 37 Posts
  • 31 Reply Likes
WOW. My Pentax K5ii time is 51 seconds for DNG files to load; both direction it loads images until it is "clear". I tested 12 mp jpegs from point and shoot camera, and the time is 34 seconds; it "loads" images only one way, reverse are loaded instantly. Interesting is that "loading" new image is similar long. 2s for JPEG and 2,5s for DNG. But that is when I try only 10 images after system is settled. In real life, where I want to do little tweaks on every image after 100 or so images loading can be 5s or longer. PC must be restarted. 

I have i7-3920K at 4.1 Ghz / 12 logical cores
32GB ram 2133
GTX 770 4GB
Windows 7 on (dedicated) SSD
(Tested) images on 4TB hard drive
Catalog on (dedicated) SSD
Cache 99 GB on yet another (dedicated) SSD

It seems all theese SSD's help on loading image, but regular editing is not affected by them. Lr 2015.10 is by feel 10-20% slower than before update. But that is notthing since it was not fast even before. What annoys is that system clogs up after a while. 

Lightroom version: CC 2015.10 [ 1111918 ]License: Creative CloudOperating system: Windows 7 Version: 6.1Application architecture: x64System architecture: x64Logical processor count: 12Processor speed: 3,2 GHzBuilt-in memory: 32692,0 MBReal memory available to Lightroom: 32692,0 MBReal memory used by Lightroom: 645,0 MB (1,9%)Virtual memory used by Lightroom: 741,0 MBGDI objects count: 628USER objects count: 1492Process handles count: 1315Memory cache size: 83,1MB / 7917,0MB (1,1%)Maximum thread count used by Camera Raw: 12Camera Raw SIMD optimization: SSE2,AVXCamera Raw virtual memory: 18MB / 16346MB (0%)System DPI setting: 96 DPIDesktop composition enabled: YesDisplays: 1) 1920x1080, 2) 1920x1080Input types: Multitouch: No, Integrated touch: No, Integrated pen: No, External touch: No, External pen: No, Keyboard: NoGraphics Processor Info: GeForce GTX 770/PCIe/SSE2
Check OpenGL support: Passed
Vendor: NVIDIA Corporation
Version: 3.3.0 NVIDIA 376.09
Renderer: GeForce GTX 770/PCIe/SSE2
LanguageVersion: 3.30 NVIDIA via Cg compiler
Application folder: C:\Program Files\Adobe\Adobe LightroomLibrary Path: D:\Lightroom\Lightroom Catalog.lrcatSettings Folder: C:\Users\STUDIO\AppData\Roaming\Adobe\LightroomInstalled Plugins: 1) AdobeStock2) Canon Tether Plugin3) ColorChecker Passport4) DxO OpticsPro 105) DxO OpticsPro 10 Importer6) Facebook7) Flickr8) Leica Tether Plugin9) Nikon Tether PluginConfig.lua flags: NoneAdapter #1: Vendor : 10de Device : 1184 Subsystem : 84651043 Revision : a1 Video Memory : 1989AudioDeviceIOBlockSize: 1024AudioDeviceName: Speakers (Realtek High Definition Audio)AudioDeviceNumberOfChannels: 2AudioDeviceSampleRate: 48000Build: LR5x8Direct2DEnabled: falseGL_ACCUM_ALPHA_BITS: 16GL_ACCUM_BLUE_BITS: 16GL_ACCUM_GREEN_BITS: 16GL_ACCUM_RED_BITS: 16GL_ALPHA_BITS: 0GL_BLUE_BITS: 8GL_DEPTH_BITS: 24GL_GREEN_BITS: 8GL_MAX_3D_TEXTURE_SIZE: 2048GL_MAX_TEXTURE_SIZE: 16384GL_MAX_TEXTURE_UNITS: 4GL_MAX_VIEWPORT_DIMS: 16384,16384GL_RED_BITS: 8GL_RENDERER: GeForce GTX 770/PCIe/SSE2GL_SHADING_LANGUAGE_VERSION: 4.50 NVIDIAGL_STENCIL_BITS: 8GL_VENDOR: NVIDIA CorporationGL_VERSION: 4.5.0 NVIDIA 376.09GPUDeviceEnabled: falseOGLEnabled: trueGL_EXTENSIONS: GL_AMD_multi_draw_indirect GL_AMD_seamless_cubemap_per_texture 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_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_program_interface_query GL_ARB_provoking_vertex GL_ARB_query_buffer_object GL_ARB_robust_buffer_access_behavior GL_ARB_robustness 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_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_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_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_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_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_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_shader_objects GL_EXT_separate_specular_color GL_EXT_shader_image_load_store GL_EXT_shader_integer_mix GL_EXT_shadow_funcs 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_integer GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_shared_exponent GL_EXT_texture_sRGB 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_KHR_no_error GL_KHR_robust_buffer_access_behavior GL_KHR_robustness 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_square GL_NV_command_list GL_NV_compute_program5 GL_NV_conditional_render 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_fence GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_framebuffer_multisample_coverage GL_NV_geometry_shader4 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_shader5 GL_NV_half_float GL_NV_light_max_exponent 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_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_shader_atomic_counters GL_NV_shader_atomic_float GL_NV_shader_buffer_load GL_NV_shader_storage_buffer_object 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_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_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_NVX_conditional_render 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_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 
Photo of Mike S

Mike S

  • 38 Posts
  • 13 Reply Likes
To gather more data, and refresh my memory on why I've stuck with 2015.4 for the past year, I rolled 2015.10 back to 2015.4 and reran my tests (just to verify repeatability).  I then installed 2015.5 and ran the tests two more times (I restarted the computer between tests 1 and 2).  Lightroom was broken in the 2015.5 update.  Here are the results reported above, along with the data from the last 3 tests.  Notice how close the 2015.5 results are to the 2015.10 results:

Results:
Moving through 10 images right, then left:  
  • 2015.4 =             23s
  • 2015.4 (retest) = 21s
  • 2015.10 =           33s
  • 2015.5 (1) =        27s
  • 2015.5 (2) =        28s
Develop 20 images.  Splits for each set of 5: 
  • 2015.4 =              22s, 24s, 22s, 21s
  • 2015.4 (retest)     21s, 19s, 17s, 17s
  • 2015.10 =            39s, 63s, 87s, 123s
  • 2015.5 (1)            33s, 56s, 97s, 128s
  • 2015.5 (2)            35s, 54s, 105s, 138s
I'll try rolling through a couple more updates to see if results stay the same.  In the meantime, I'm curious if anyone else with this Development module slowdown problem sees improvement when rolling back to 2015.4.  I've been using it for the past year, in sessions running 100's of images, and have never seen the degradation of performance that has shown up in the updates above. 
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 5994 Posts
  • 1320 Reply Likes
Thanks for the detailed information, Mike.  I am curious to see if someone can duplicate what you are seeing between @015.4 and 2015.5 (alas - my system don't degrade in 2015.5 and later)
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 5994 Posts
  • 1320 Reply Likes
@ Mihael, 51 seconds is brutal!  Would you mind sharing that image with me from your Pentax? 
Photo of Mike S

Mike S

  • 38 Posts
  • 13 Reply Likes
Rikk -- What additional information can I provide on my system?  Do you want the catalog and images for testing?  If its not happening on your system, yet its easy to reproduce / turn off and on on mine (and its also easy to find people complaining about performance degradation in the Develop module), doesn't that point to a gap in your testing systems?  I'm just using an off-the-shelf Alienware laptop, that is super fast on 15.4 and unusable on all updates after that.  Unfortunately, I want to buy a new camera that requires 15.10 for support, so I need to find a solution.   
Photo of Mike S

Mike S

  • 38 Posts
  • 13 Reply Likes
Rikk -- one other question about your system:  how many CPU's / cores are you running on your test system (where you don't see any degradation from 2015.4 to 2015.5)?  I was reviewing another post (https://feedback.photoshop.com/photoshop_family/topics/lightroom-clone-and-brush-tool-can-not-stress...) and the issue with multiple cores came up (though I can't find any evidence that this is an 'acknowledged' problem).  So I tested 2015.5, setting different affinity masks.  I'm running 4 dual-core processors for a total of 8 possible CPUs.  Its hard for me to believe that you can't duplicate the problems.  Here's what I got, running the basic test of applying my simple preset to 20 images (resetting each one after the preset is applied):

Times are seconds to process first 5 images, 2nd 5, 3rd 5, and 4th 5
Mask FF = all 8 processors:     26       46      80     117
Mask 3F =      6 processors:     19       35      58      83
Mask   F =      4 processors:     18       25      31      43
Mask   3 =      2 processors:     26       32      35      37
Mask   1 =      1 processors:     26       27      25      27  !!!!!!!!!!!!

It seems pretty obvious that something in the way you handle multiple processors changed between 2015.4 and 2015.5.  In 2015.4 no masking was required, and the time required to process image 20 was identical to the time to process image 1.  To get that same result in 2015.5,  all but 1 processor must be turned off.

Unfortunately, turning off all but 1 processor slows the time it takes to get anything done, and least at the start.

Its also obvious that as more processors get added, the degradation gets worse.

I believe some changes were made in 2015.10, so I'll check that next.  But is there an 'acknowledged' problem anywhere on this forum that discusses the need to set Lightroom affinity?
Photo of Mihael Tominšek

Mihael Tominšek

  • 37 Posts
  • 31 Reply Likes
51 seconds was to open Lr, select image and wait to settle. Than use cursor to navigate to next image and start the stopwatch. Wait until the image is at it's best resolution (first it loads low res thumnail, than full res image renders). And when it does go to next image. For 10 images, than back to first one. for DNG (16MP Pentax K5) in both direction it needs it's 2-3 seconds to load image (depending on how detailed is, I guess). With JPEG's selecting images that were already selected they loaded instantly. 

I used smartpreview... but have problems with it, I guess... bellow I will post the result of my test with that. 
Photo of Denyer Ec

Denyer Ec

  • 55 Posts
  • 43 Reply Likes
In video 3 I have the CPU graph open whilst an import is in progress. All 4 cores are in use, but Mike S's numbers above suggest that whilst all 4 cores are busy, they might not be usefully so - especially if they're interlocked or in some kind of race condition.

In an ideal world, one core would be left alone for UI and one for Develop so that one can continue to work during an import/export - however I've long since developed the working habit of starting both of these operations before going to bed, as they take so long and so thoroughly tie up the machine that I can do nothing else while they're running.
Photo of Denyer Ec

Denyer Ec

  • 55 Posts
  • 43 Reply Likes
In video 3 I have the CPU graph open whilst an import is in progress. All 4 cores are in use, but Mike S's numbers above suggest that whilst all 4 cores are busy, they might not be usefully so - especially if they're interlocked or in some kind of race condition.

In an ideal world, one core would be left alone for UI and one for Develop so that one can continue to work during an import/export - however I've long since developed the working habit of starting both of these operations before going to bed, as they take so long and so thoroughly tie up the machine that I can do nothing else while they're running.
Photo of Mike S

Mike S

  • 38 Posts
  • 13 Reply Likes
So I ran 2015.10.  The good news is that multi-core performance is faster overall than in 2015.5.  The bad news is that the degradation problem on multiple cores still exists -- it just takes longer to get to "give-up-and-restart" levels.  Here's the data:

REPEAT OF 2015.5 FOR REFERENCE
Times are seconds to process first 5 images, 2nd 5, 3rd 5, and 4th 5
Mask FF = all 8 processors:     26       46      80     117
Mask 3F =      6 processors:     19       35      58      83
Mask   F =      4 processors:     18       25      31      43 <-- best early performance
Mask   3 =      2 processors:     26       32      35      37
Mask   1 =      1 processors:     26       27      25      27 <-- no degradation

2015.10
Times are seconds to process first 5 images, 2nd 5, 3rd 5, and 4th 5
Mask FF = all 8 processors:     26      38      56      80 
Mask 3F =      6 processors:    18       24      35      49
Mask   F =      4 processors:    16       17      23      28 <-- best early performance
Mask   3 =      2 processors:     24      29      28      29
Mask   1 =      1 processors:     23      25      24      26 <-- no degradation

Simon Chen posted an experimental mod on the other thread I mentioned that limits Lightroom to the 'Mask F' condition, so I'll try that later today just to see if the results change.

Rikk -- can Adobe duplicate this multiple-core problem, and if so, can it be 'acknowledged' somewhere with suggested workarounds (particularly noting that, for systems like mine, the absolute worst case performance is simply starting lightroom unmasked -- the way 99.99% of the world uses the product)?  That would at least help people who are currently stumbling around looking for solutions, and can't find anything official that even brings the issue up.  It would also be helpful to know the conditions when it may be helpful to run all processors, vs when it might be best to only run 1.  My testing was only on something as simple as applying slider presets.  But import/export, building previews, brush work, etc all may exhibit either better, or worse, overall speed depending on what exactly is going on.
(Edited)
Photo of Melissa Rios

Melissa Rios, Lightroom Support Product Manager

  • 104 Posts
  • 25 Reply Likes
Thanks, Denyer, for the post!
Photo of Denyer Ec

Denyer Ec

  • 55 Posts
  • 43 Reply Likes
Hmm, seems I'm either unable to edit the original post, or unable to find the edit button...

To address Rikk's comment, GPU Accel was disabled for the vast majority of the videos, as it causes strange artefacts and screen behaviour as demonstrated in video 2.

I should also add that the original videos were produced on a "Nearly Clean" windows installation - I rebuilt a new workstation from scratch to try and improve LR performance, the irony of which is not lost on me :) The installation of windows (And subsequent profiles etc) were only a few weeks old, with not much besides PS CS5, LR and web browser installed.
(Edited)
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 5994 Posts
  • 1320 Reply Likes
I edited the post title already so it is good. 

The Slider/Brush behavior you describe is typically GPU related which is why I am asking. My home system is very similar to yours (I have the same video card and Ram) but I don't see these behaviors. (I have GPU enabled). 

If you will indulge me for a test can you:

1. Create a new catalog for test purposes and import a few of your bigger (file size) images into the test catalog.
2. Turn off GPU in Preferences.
3. Restart your computer.
4. Launch Lightroom with the test catalog. 
5. Attempt the Slider and Brush adjustments that have been plaguing you. 

Are you seeing similar lags in this test environment? Differences?
Photo of Denyer Ec

Denyer Ec

  • 55 Posts
  • 43 Reply Likes
Hey Rikk,
Apologies for the delay, real life has a nasty habit of kicking me in the teeth at the moment :/

I tested the new catalog as you suggested but see no performance improvement beyond initial LR loading speed (As you'd expect with a small catalog devoid of images and presets/preferences).

Performance is still very similar to my recorded videos, though without the impediment of the memory leak worsening things over time.

Are there any tools, perhaps something like Windows Performance Monitor or some such (I'm not a Win32 developer so my knowledge here is terrible) that could be attached to generate meaningful debug information to help with isolating the causes ?
Photo of Risto Kuittinen

Risto Kuittinen

  • 7 Posts
  • 1 Reply Like
My gpu-support broke down after the latest update to 2015.10.

Lightroom crashes when in library mode and selecting a tiff-file and then switching to develop mode. Ticking off the gpu-support cures the problem. I have the newest gpu drivers and win10 (1703). Gpu is amd R9 380.

I'm tired of being a betatester. Previous version was the pretty good though (it didn't crash).
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 5994 Posts
  • 1320 Reply Likes
@Denyer. Thanks for testing. I am still gathering data from the participants in this thread. 
Photo of Matt Quinn

Matt Quinn

  • 6 Posts
  • 5 Reply Likes
I have the same problem as Risto. I recently updated my AMD RX480 graphics drivers on Windows 10 and now I can't use the develop module without LR 2015.10 crashing. If I disable the GPU then everything works great.
Photo of Sasha Torilo

Sasha Torilo

  • 1 Post
  • 0 Reply Likes
Thanks, deselecting GPU acceleration resolved my slow Lightroom issue
Photo of Steve Gandy

Steve Gandy

  • 133 Posts
  • 43 Reply Likes
Is storing your images on a RAID device supported? My disk is straight data disk  and is  connected via thunderbolt. I don't notice laggy performance.
Photo of Denyer Ec

Denyer Ec

  • 55 Posts
  • 43 Reply Likes
Logical RAID drives appear as single volumes in Windows, I don't think LR would have any insight into what is/isn't a RAID device? As I (And I'm sure many others) require the redundancy in case of a drive failure, an incompatibility with RAID (Software and hardware) would be beguiling - especially as from a software level the disk(s) will appear as a single write target.

Could be wrong, but it'd be super unlikely - I can test it by plonking my latest shoot onto a single disk and then running the test that Rikk outlined above.
Photo of Mihael Tominšek

Mihael Tominšek

  • 37 Posts
  • 31 Reply Likes
I am cutting my venes with Lr from version to version. Every (every!) version of Lr is slower / more laggy. Regarldless of hardware.  Years ago I started with Lr 1.5 and I had 3 MP JPEG's - Yes 3MP , but on Celeron (Pentium 4 era) with 512 MB ram!  I thought this is the best software on planet. 

I started to curse Lr after version 4... I upgraded hadrware to have latest and gratest. 3 SSD's: images on one, 99GB !!! cache on another, catalog on third... I have SAME camera now for 3 years, still performance degardes. I it laggy EVEN if I go to edit thoose 3 MP files from 10 years ago. I have 2 computers with 6-core CPU, (one have HDD's and 16 GB ram, and older GPU, other have 32GB and SSD's and newer GPU), but no difference on them regarding Lr. 

Sometimes (?!?) for some projects it works better, another day it is to pull hair slow. I started to use smart previews. The day I changed that setting it was FAST... ok, at least workable. But another day, same as before. Than GPU... when I enable it, Lr works better and CPU cooler is quiet, so GPU works. But Brushes are insane than. If unticked, brushes are more alive but Lr is a bit slower. I hear CPU cooler... with latest update, if I select / change 2-3 images fast one after another, the CPU works a lot, but it seems only few threads, since CPU get hot (cooler wakes) and Lr is almost unresponsive until image "loads" 100%, but only few cores out of 12 of my CPU is utilised. BTW making 1:1 previews upfront does nothing to performance. 

Lr on that beast machine is almost no faster than on my 5 year old laptop with 8 GB of ram. Making new catalog for project does nothing. While exporting there is the only time whine CPU goes 100% with all 12 cores and export is VERY fast on my fastest machine and not so on slow laptop.

Photoshop have no issues, CorelDRAW/PAINT no issues and Capture One works smooth as butter. Only LR is hessitating SNAIL. Another aspect of bloated Adobe software code is Primiere, which is similar on performance and I started to thinking of harakiri. But than latest version after patches gived me hope, as I work now OK. Even I say "OK" (25 years on NLE's all from Avid, etc). So Lr need to be revamped. This is insane. We do not need ever new functions that bloats basic functions such are brushes, crop, etc... not to mention perspective correction. 
Photo of Mihael Tominšek

Mihael Tominšek

  • 37 Posts
  • 31 Reply Likes
Sorry for all spells... I can not edit the comment anymoore.
Photo of Tom Peterson

Tom Peterson

  • 7 Posts
  • 12 Reply Likes
What's most surprising about all of this is that Adobe seem to want to make it look as though this is some sort of specific issue?
This is a universally known problem. Nobody can build a computer fast enough to run LR.
I was in the same boat. Always loved LR and most Adobe software, but over the last year I canceled my subscription and stopped editing. 
I won't start again until this is resolved for the vast majority of users.
Everywhere I look people with outrageously expensive computers can barely run LR (I am one of those people) and I will not post log files and pretend this is a support issue.
This is a general problem and must be addressed somehow. It has to be possible, because LR used to run better.
Though it hasn't run _well_ for years. It should feel like Photoshop. But it doesn't.
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 5506 Posts
  • 1157 Reply Likes
Adrian, 

I would love to have system information from you as well. I would love to get to the bottom of this issue. 
Photo of Tom Peterson

Tom Peterson

  • 7 Posts
  • 12 Reply Likes
Just system specs? Core i7 920, 32gb ram, win 10 x64, Samsung 950 SSD...

But again, I can also run it on a Core 2 Duo laptop with a mechanical HDD and 4gb of ram and it barely makes a difference :(

Even the difference between 8mp all the way to 42mp raws is not very noticeable.

The biggest difference stems from displaying LR on a 1080p vs 4k monitor (perhaps an obvious statement considering how much more processing will be involved in that)

I have stored the catalogue and pictures on dedicated SSDs and normal HDDs with no real difference in performance either.
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 5506 Posts
  • 1157 Reply Likes
Thank you.
Photo of Art M.

Art M.

  • 87 Posts
  • 18 Reply Likes
I agree with Tom.   I realize Rikk that you need specific information to identify the problem but at the same time, Lightroom is simply notorious for massive slowdowns.  On the other hand, it has fantastic functionality which is why so many of us keep using it despite the slowdowns.  Honestly I expected to have to switch to Photoshop by now but I find that I keep learning about additional functions in Lightroom that cover my needs.

And I do want to thank you Rikk for taking a serious interest in the problems.

There is a lot of speculation that Lightroom only uses one core on multi-core machines.   Perhaps you would investigate this?   Do the Apple and Microsoft API's make it easy or hard to program to use multiple cores?

Next time I have a massive slowdown in editing I will video it on my iPhone and send it to you along with all the system configuration information I can think of.  

In the meantime, please note carefully that I personally experience slowdowns in two specific situations:

A.  Scrolling through RAW photographs in G mode when I have not previously created 1-1 previews.   Some people in dpreview forums have speculated that Lightroom is not taking advantage of the JPEG's embedded in the RAW files.  This of course would only be helpful until one begins to edit the files in Lightroom, .....  but I usually only scroll through ALL the photographs in a shoot initially to do ranking, prior to any edits at all.  I bet that is a common workflow. 

Seems like this could be corrected.  Would you please check this out?

This particular problem is so well known (slow scrolling of RAW files) that some firms have developed products just to deal with it, such as FastRawViewer or Photo Mechanic. 

Creating 1-1 previews solves the scrolling problem (until I have do some edits) but that itself is a slow process that uses a lot of hard disk.  For this reason I usually do NOT create 1-1 previews until I have done the initial culling of my shoot.

B.  Here is the big one:   after I have done some edits, maybe 10 to 20 edits, to a photograph, further editing slows down a LOT.    I do use the brush for dodge and burn quite a bit as well as the clone/heal function.  That should be a clue. 

It feels as if Lightroom is recreating the entire image from scratch from history every time I do an additional clone/heal or brush.   Crazy.  There might be something extraordinarily inefficient about the way that process is programmed.  I can't help but think that there is an algorithmic fix possible here.   Would you please check this out?

Another clue is that to my best recollection, speed problems escalated dramatically with the transition from v5.7 to 6.x and CC.   Can you check out whether something fundamental changed there?

System: As I mentioned earlier, I keep 100gig open on my SSD, I have a 2015 MacBook Pro I7 with 16gig, I bumped the cache to around 30gig, and I seem to experience similar problems whether I have GPU turned on or off.   I do keep several had drives attached to my computer as backup drives.    I edit with an external monitor that is 4k 24" run in 2k mode.  My MacBook Pro is rated to drive this monitor just fine and it does.

Finally, I have noticed that closing all internet browsers speeds up Lightroom a bit. I find that open browser pages use a lot of CPU even when they are doing "nothing".   Something is afoot with the advertisers doing work in the background, I suspect.  Sigh.   So I do encourage Lightroom users to keep browsers closed where possible.

Thanks very much for your assistance Rikk.
Photo of Denyer Ec

Denyer Ec

  • 55 Posts
  • 43 Reply Likes
There are a LOT of people with performance issues (More than I know than without) but there are some people out there who don't have performance problems and can work quite happily with the software.

Either they are far, far more tolerant then we, or there is something system specific afoot. That said, I've built 2 computers for Lightroom so far, and both have sucked, so the problem is at least quite widespread, or my luck is just terrible :D

(Or there is some seemingly innocuous piece of software that I absentmindedly install every time (like the Wacom drivers or Crashplan) that ruins LR's performance somehow?)
Photo of Mihael Tominšek

Mihael Tominšek

  • 37 Posts
  • 31 Reply Likes
True! Saddly. 
I use Lr, Pr, Au and Dw for at least 10 years. For all mentioned hold true that they perform progressively slower from version to version (not much, but noticable) and MUCH (MUCH!!) slower than their first versions (which was bought from other developers). The only Premiere blessed me with major speed improvement in CC2017.1 compared to CC2015.x.

I use other packages like Ps only from 2013 after CC enabled me to have them all. And Ps is only package that perform good in every version. 

My system was installed 14.8.2015 - only hardware changes during that time was 16-32 GB ram and I regularly update SSD's here and there. On the same system I have currently installed 4 versions of Premiere:  CS6 (for Encore), CC"2013" (for third party plugin that I use a lot), CC2015 (used to be main editor), CC2017.1 (is main editor now since "0.1" update). 

- CS6 was perfect.
- CC was the same fast and stable, just few things changed that annoys me. 
- CC2014 introduced UGLY GUI... refused to use it...
- CC2015 a bit toned down blue color and added few interesting features. After a good year or so, I stzarted to use it. It was REALLY stable version, but obviously under the hood updates ruined performance since it was slower and slower when using LUT's especially. So bad I wanted to make suicide (not joke) when I had deadline with huge lawsuit behind if I do not deliver. And Premiere wanted 10 seconds to refresh screen for every cut, slide, change... and sometimes 5 minutes to draw initial screen of timeline. In a desperation I tried CC2017 again, which I refused to use due to the most crashing Adobe package ever (crashed almost every time a mouse was moved). I rather never update Adobe software anymoore so "updates" are blinking in my CC note area. I clicked update for CC2017 and tried it. I opened same project that did not open under 10 minutes in CC2015. After conversion I was shocked! Is that possible? Opened instantly, no LAG what so ever... And this is converted project from CC2015. Wow... let it crash every minute I said... I have dedicated SAVE key on my custom keyboard anyway (because Adobe). But hey... it only crashed 2-3 times during workday. Yes with CC2015 I do not remember it's last crash, so much I forgot to save... now I'm saving again, but CC2017 on same old Windows, works great, where CC2015 is a nightmare... nothing changed.

I hope some LR version will bless me with major speed increase as Premiere did... until than, slight improvement is not worth speaking. We need 400% improvement. 

I tested old JPEGS. My fisr digital camera have 1024*768 files. Thoose files work fast! 5MP RAF, 9MP RAF, 12MP JPEGS, 16MP DNG (out of Pentax), all work similarly slow. If system is "rested", it loads image in 2 seconds. "loads" is where detailed image is processed, not when low res thumbnail is shown. After system is "tired" (working on 100 files for a while jumping back and forth adjusting smlla changes here and there, tweaking...), it could load 3-5 seconds per image. 

I do use "smartpreviews" as proposed a while ago for speed increment. That was good only for the time I swithed... That day LR was pleasure. Not blazing fast, but no lag. Only thast day! I do not understand. 

PS: I will test SMARTPREVIEWS vs. NORMAL
Photo of Dennis

Dennis

  • 2 Posts
  • 1 Reply Like
Im afraid Im in the same boat. I can't afford the time this is costing me so I am exploring some of the other catalog/editors out there.
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 5994 Posts
  • 1320 Reply Likes
For those of you on this thread who are using Windows-based systems who has completely uninstalled their graphics drivers (not just updated) and then reinstalled from your manufacturer's latest version?
Photo of Denyer Ec

Denyer Ec

  • 55 Posts
  • 43 Reply Likes
I was working from a completely clean (Non-upgrade) installation of windows 10 if that counts? I have always had GPU Acceleration disabled due to the strange colour shifting and display behaviours it caused.

(A segue I admit - but does anyone benefit from GPU Accel? Every thread I read says to turn it off, makes me wonder! :) )
Photo of Victoria Bampton - Lightroom Queen

Victoria Bampton - Lightroom Queen, Champion

  • 5173 Posts
  • 2021 Reply Likes
> does anyone benefit from GPU Accel?

Yes - the specific people it was designed for - those running 4K and 5K monitors. Even then, there are downsides to consider (brushes are slower) but it makes Lightroom useable on those high res screens. Most people with standard res screens are better with it turned off.
Photo of Mike S

Mike S

  • 38 Posts
  • 13 Reply Likes
It looks like I did a complete uninstall / reinstall back in December (for other reasons -- nothing LR related).  I was running 2015.4 at that time, and wasn't having any problems before the uninstall (and haven't had any problems with that version since).  All issues are on the > 2015.4 updates.
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 5994 Posts
  • 1320 Reply Likes
@Denyer EC - that doesn't count. I am looking to see if anyone has completely uninstalled their drivers and reinstalled from scratch after an OS installation. 
Photo of Denyer Ec

Denyer Ec

  • 55 Posts
  • 43 Reply Likes
Ahh OK, that's easily done for you, I can sort that out now if you'd like?

Would you recommend using the nVidia "Driver Cleaner", or do you suggest simply removing them via Add/Remove Programs  in Control Panel?
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 5994 Posts
  • 1320 Reply Likes
At this point, I am just curious. We had a report from a user in the Adobe User to User forum who had similar performance issues. They ran diagnostics on their machine and found 2D video operations were lagging badly. An uninstall of the video software and reinstall restored functionality. 

If you are comfortable with the process, it is worth trying. 

I was just trying to gauge if any of those reporting performance issues had attempted this to get more data points. 

https://forums.adobe.com/thread/2307390
(Edited)
Photo of Denyer Ec

Denyer Ec

  • 55 Posts
  • 43 Reply Likes
At this point I'd happily start drawing pentagrams on the floor with salt, so I'll give it a go and report back.
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 5994 Posts
  • 1320 Reply Likes
I won't guarantee pentagrams are unlikely to help but I strongly suspect they are. Let me know what you find.  Also, an engineer should be in contact with your shortly via email.  Is the email on your account here valid?
Photo of Denyer Ec

Denyer Ec

  • 55 Posts
  • 43 Reply Likes
Yes, email here is fine - thanks for letting me know as the spam filtering can be quite aggressive.
Photo of Matthew George

Matthew George

  • 24 Posts
  • 9 Reply Likes
I had an Adobe rep do this for me during a help session. It didn't have any effect.

NVIDIA Quadro K1100M
Photo of Jerry Syder

Jerry Syder

  • 329 Posts
  • 147 Reply Likes
Hey Rikk, just jumping in to say that I did a complete uninstall of everything NVidia and reinstalled but it's still as bad. Are we seeing an NVidia trend here? Windows 10 here too and similar spec to the others. Lightroom CC, NVidia 1060, 16GB Ram etc
Photo of Dennis

Dennis

  • 2 Posts
  • 1 Reply Like
I did too, no joy.
Photo of Mihael Tominšek

Mihael Tominšek

  • 37 Posts
  • 31 Reply Likes
So SMART vs REGULAR previews: 
I use 2 monitors. On second monitor I have 1:1 preview selected. So I can see when image is rendered to highest resolution. It takes some time. 

1) discarded smartpreviews and 1:1 previews. No image in folder selected. All images are 16MP DNG (Pentax), and already edited. All have with same preset applyd, but some with aditional brushes, radial filters and spot healing and perspective correction. 

First 6-7 images needed exactly 5 seconds to be fully rendered after clicked on it. Than it was close to 6 for every image after that. Thoose with selective effects needed 8-12 seconds. I found out that perspective does not take much, most peformance hit is with brush and radial. Spot healing is slow to operate, but renders fast. What I found is that sometimes image on second monitor renders seconds after it is rendered on main window and sliders come back. Sometimes image renders much faster and sliders needs 10 seconds to show (sliders are gray during image loading). 

This is not usable. If I need to load 250 images (average shootout) that is 30 minutes just to open them once. Multiply that with 10 per image during workflow that damn thing I'm paying regularly and not that little (e.g. Lr) takes me 5 hours of WAITING on average job. That means I loose 5*20 EUR (my low hourly rate) = 100 EUR / job. Thank you Adobe! I must charge more on already compating market or I just buy competition licence. Unfortunately, not using Lr does not save my bill, sicne I use Premiere which thankfully works (until next update). 

2) Build 1:1 previews (in the prefferences "use smart previews" is unticked):
Images loads mostly instantly, some of them needs 1-2 seconds to render. So this is what I need. But I only tested 20 images. That means nothing since I did not test to work several hours. While image loads instantly, sliders still needs to "load": That is probably to render effects. Still this is much faster than using no previews. It takes 2-4 seconds to load sliders in develop mode. 

3) Discard 1:1 previews and Build smart previews (in the prefferences "use smart previews" is ticked):
Some of images loads instantly. Most of them renders (loads) for about 2x the time as with 1:1 previews. Processor works much harders as my 1KG cooler starts to spin when working with smart previews, but is quiet with 1:1. Than another issue: Screen blackouts - some parts of tool panes blacks out. And approaching to next images demands several clicks until it goes. Even after image is rendered fully, it refuses to approach to next image and CPU cooler goes like mad. When cooler calms dow, the next image is loaded.

Interesting  that sliders loads at about 1/2 the time as with 1:1 previews. 

Cocnlusion: I will stop using Smartprevirews since it ruins performence, not improves it. Image loads quicker under 1:1 since it is prerendered. SmartPreview probably tryes to render 1:1 on the fly. It is even slower or similar than no previews at all. But sliders loads faster in Develop mode since effects are rendered at lower resolution file. (I guess). 

Let's try the performance when tweaking the images.
The most annoying is perspective tool. The nods jumps all over so it is pain to adjust it right. Furthermore they stick to mouse and even you placed them and released mouse button it is dragged by moving mouse to somewhere out of screen. Same happens sometimes in brush editor (if GPU is selected, for shure).

Another  annoyance is that on second monitor mouse click enlarges the image to 2:1, only than it is rendered to 1:1 as selected. And another click  does not revert image back to FIT, but "fit" icon must be clicked, or another image selected, than it releasess it and revert it to fit. 

Third annoyance (long ago noticed) is masking or brushing while having image at 100%. It is fine, until you want to move it (with hand tool, pressing spacebar), or zooming (in/out) while on brush or other selective tool. Once or twice it will do with much lag, but after few inteventions it will cease alltogether. You need to close the tool, wait until system rests, than open tool, select nod, and try again... 

All in all: We pay big money to Adobe, and get this kind of software. Uggh. Sometimes I wish I would digg trenches for living, because there every shovel of dirt you lift, it is one less in the trench and you can see the progress. With Adobe software (mostly) you can see only suffer and little progress / joy. Sorry folks, that is how I (we?) see it after 10+ years with ever the same problems. New version will supposedly be better right. 

Lets' try to edit some NEW previously unedited images: 
Same crappy sluggish performance. Yes 1:1 previews loads image faster, but editing is a bit slower. Even paning image at 100% is laggy (1-2 seconds to move, if it moves in first attemtp) and zooming on an image still takes long. Using smartpreviews editing is a bit faster but you loose insight of image quality (sometimes I even reject image, which is fine otherwise), and image loading is double the time. So I guess I will NOT use smartpreviews from this test on. In fact... 

FINAL CONSLUSION:
I will not use Lightroom until this is sorted out and Adobe release new version with some "mercury playback engine" which will clain REAL TIME EDITING again. 

I'm sick of wasting my life on this forums, where we chase our tails debugging something for which we pay ADOBE to do it for us. We bought tool, not opportunity to debug one ourselves. We need something that works. Something that competition already have. 

I reckon Adobe gives a *** if I leave. I will still pay for compete CC for other software (that I mostly curse as I do Lr). And even if I leave completely... huge stream of new customers comes in. Lightroom is amateurish software. It is great if you only open image, apply preset, press auto upright, auto lens corection and export (to social media from Lr directly). Thoose people are slow for masking by themselves or they do not mask competelly, so they do not know it is slow. They are attracted to make panoramas, HDR's, "books", and "slideshows", use (ugly) dehaze tool ...

We need speed.

Maybe I will make comparison video of editing 20 images using Lr and other tools.  
Photo of Denyer Ec

Denyer Ec

  • 55 Posts
  • 43 Reply Likes
You and I seem to have similar experiences with speed and frustration, though in a conversation I had on twitter with Melissa, it at least felt like they are starting to take things seriously - hey, if they don't, we leave right? (Oh, you have tried the metadata tools in Capture One, haven't you? Ye gods.)

I found that using OBS Studio to screen-capture lightroom was the easiest way to relate performance to the tech staff, once people see just how paintful it is to use on your system it becomes very hard to ignore, but times and numbers are somehow abstract to process.

Also in agreement, is that if it takes 6 seconds to change between images and I have 1500 images to work through, that's  2.5 HOURS of time wasted just waiting for slow software. That's billable time, and it's really hurting my margins :(
Photo of Tom Peterson

Tom Peterson

  • 7 Posts
  • 12 Reply Likes
You two said it perfectly. This is the crux of it. The second there is any viable Adobe competition, I will go with that. Until then, I will not use any Adobe software anyway. 
So the only way to get me back will be performance improvements.
I am not getting my hopes up. Thank god I don't need to use this stuff professionally.
Photo of Brandon Harvard

Brandon Harvard

  • 1 Post
  • 1 Reply Like
I also have issues with very poor performance with Lightroom CC 2015.10.

System is:
Intel i7 5820K @ 4.2Ghz
24gb ddr4
Nvidia GTX 1080
Library is on Samsung EVO 850 SSDs in RAID arrray. 

Brush performance and gradient adjustments are especially bad. I often use 10 to 12 circular gradients for dodge and burn and by the time I get more than 4 or 5, they become hard to manipulate or place accurately because just trying to move them takes seconds, and the refresh rate drops off a cliff.

I have disabled GPU acceleration - but overall it actually seems worse in most other situations, although it does improve the brushes slightly.

Overall, the performance of Lightroom is far far behind Photoshop for me.
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 5994 Posts
  • 1320 Reply Likes
Thank you to you all for contributing your experiences to this thread. Engineering is taking a look at the issues presented here and may be contacting some of you directly via email with more questions. 
Photo of Matthew George

Matthew George

  • 24 Posts
  • 9 Reply Likes
Happy to do whatever I can to help. Would love to see it fixed.
Photo of Simon Ringsmuth

Simon Ringsmuth

  • 4 Posts
  • 4 Reply Likes
Just chiming in to say that LR performance continues to get worse over time. It seems like product development has shifted to the mobile space rather than improving the desktop experience, which is frustrating for myself and so many other photographers who need fast loading, culling, editing, and exporting.

I use LR at home and at work, and specs on both systems are similar:

iMac 27-inch, Mac OS Sierra
3.4 GHz Core i7
16 GB RAM at work, 32 GB RAM at home
3TB Fusion Drive
Library is on the internal drive

Zooming to 100% results in 10-15 seconds of loading time per photo, which makes it extraordinarily time consuming to check for sharp images.

I like LR just fine, but it's slow, slow, slow. Please speed focus on speed improvements for desktop rather than adding new features for mobile.
Photo of Kyle Ford

Kyle Ford

  • 1 Post
  • 2 Reply Likes
I also have had issues with performance. 16GB RAM on a 2012 MBP. I've gone so far are to start using CaptureOne. My photos are kept on a RAID 5 box over thunderbolt, the drive is plenty fast. 
(Edited)
Photo of Simon Ringsmuth

Simon Ringsmuth

  • 4 Posts
  • 4 Reply Likes
How do you like Capture One? Do you find that it does everything you were used to in Lightroom?
Photo of Art M.

Art M.

  • 87 Posts
  • 18 Reply Likes
I use Capture One for tethering. Fantastic. I took courses on editing with Capture One and learned that C1 has superior color manipulation but I was not able to confirm that it has everything I use frequently in Lightroom such as radial or graduated filter. I stopped the editing experiment with C1 at that point. Also I wondered whether C1 could replace Photoshop but it is limited to 16 layers. I may try again at some point.
Photo of Mihael Tominšek

Mihael Tominšek

  • 37 Posts
  • 31 Reply Likes
What I like in Capture One:

- no performance issues - tools work smooth and realtime.
- more precise tools than Lr but less automated (If you like "auto" tasks and are fine with the result, Lr will be faster. If you tweak everything manually, C1 gives advantage)
- better* grain, more organic
- better* Black and white
- finer/more precise color control
- skin smoothing / color averaging (sometimes no need for external edit)
- WAY more* detail revealed (or extracted) than from Lr. It seems like new camera/lens compared to Lr. 
- Lens specific sharpening (based on specific lens profile and its design)
- more natural* SKIN colors
- for non crucial work, images are mostly fine out of the box (e.g. I shoot my children, load images to C1, export them, finito) , while in Lr I must tweak just about any photo before it's watchable (even least important snapshot)
- auto image enhance actually gives usable results. I would never (!) use Auto in Lr (always washed out look). 
- multiple recipes for export at once - Lr have them too, but separate export work in parallel, using more time than one by one. 
- it renders my Pentax cameras MUCH more acurate and better than Lr.

What I DISLIKE in Capture One:

- metadata is NOT written into files like in Lr (I shoot DNG's with my Pentax, I don't know how it is with other cameras), so sidecar files are added. I hate clutter, maybe not and issue for most. 
- ColorChecker password is near to useless - in Lr I can easily create DNG color profile - but it is less needed than in Lr since my C1 renders Pentax camera WAY better than Lr. I had severe red color problems in Lr, until I created custom DNG profiles. No such problems with oversaturated/exposed reds in C1. So maybe not an issue for most. I can make ICC profile with some elbow grese. 
- Extra subscription fee on top of Adobe. I have CC for other Adobe software as well, so using Lr only would be more economical. For photographers only CC you get Photoshop as well in same subscription. So having C1 + Ps is 2x the price. Well one could trade some image quality and tools precision for price, if Lr would work as it should. Since it wastes our time, paying extra saves us money on longer run. 
- not nearly as much lens profiles as in Lightroom. BIG diss. But yes, we can adjust that manually. I reckon this is because in Adobe lens profiles corrects only vigneting and barrel, but in C1 also sharpness fall-off; so lenses that have profile benefits more in C1 than Lr. Issue is probably not important to CaNicon shooter - there are ton of profiles, but I have rare Pentax. 
- I have some GREAT presets in Lr that I payed for and I love. Yes, Capture One have "styles" too. But for Lr there are thousands of free and non free presets on the web. I must yet discover styles in C1 before I can compare.

So I mostly prefer C1 over Lr anytime.

If I must choose one: 

I would choose lightroom if it would work smooth and fast (hear that Adobe!), because it is more convenient and integrated into adobe ecosystem and cheaper and I have great presets and I invested 10 years into mastering it. 

But since Adobe Lightroom does not work smooth or fast and was not updated it's process for 5 years, I prefer Capture One for everyday work because it is faster, more accurate and gives me higher quality or control over development. 

Reason why I still use Lightroom is because I have total CC subscription and not using it does not save me money. But soon after I replace Premiere... 

* Arguable. One would say I can be replicated in Lr as well. But per my knowledge, very hard or impossible. At the end, whe struggle if C1 gives similar out of the box. 


Hope it helps. 
Photo of Mihael Tominšek

Mihael Tominšek

  • 37 Posts
  • 31 Reply Likes
PS: C1 compared to Lr is NOT the same exerience and not all tools are replacable. Some are same, some similar, some completelly different. I can struggle all day and I cant make RAW image the same in both programs. What I can say is Capture One needs less tweaking to get decent image that Iike. Most of them are fine (usable) straight after loading in. For heavy preset* user Lr would still be faster regardless of Lr problems. 

Learning curve in C1 was 1 afternoon. But I use Lightroom for decade. I wonder how that would be for newbies.

* Sometimes I force myself to use digital body as film camera, so I must do it right in camera. Thoose images I do not tweak other than exposure. In that cases I load image into Lr, apply film simulation preset , fix exposure if needed and export it. It is fast than.
Photo of Denyer Ec

Denyer Ec

  • 55 Posts
  • 43 Reply Likes
C1's metadata tools are garbage compared to LR's. That's the only thing currently keeping me on LR - for what I do the ability to quickly add and filter disparate metadata is essential and C1 simply doesn't have the tools for it.

As for tethering reliability, I found that all my LR problems went away when I switched to a USB2 cable, with no noticeable drop in speed (Nikon D800)
Photo of Matt Quinn

Matt Quinn

  • 6 Posts
  • 5 Reply Likes
I recently built a new Windows 10 machine to replace a 4 year old MacBook Pro. The specs on the new machine are:

Intel i7 6800k
32GB DDR4 Ram
MSI Radeon RX480 4Gb GPU
Asus X99-A II Motherboard
LG 27" 4K monitor running at 3840x2160

Lightroom is 2015.10

My performance is about the same or worse running on my new machine vs. my old MacBook pro (i7 2.7ghz 16gb ram) and recently I upgraded to the latest AMD drivers and the develop module crashes lightroom. I have to disable the GPU to get into it. Before upgrading to the latest drivers the GPU would work, but the apps performance would slowly degrade over time.  Here are some of the issues I've faced:

- The screen would flash black frequently .
- Sometimes when I clicked on an image, it would flash to another image first the to the image I selected.
- Using the sliders had a serious delay associated with them, sometimes not seeing the results on screen for seconds. For example, moving the exposure slider would not update the image for a couple seconds. 
- Sometimes there is a 2-3 second delay moving between images in develop mode.
- Using brushes and spot removal is painfully slow.

These are just some of the more common problems. I've had other issues come up more randomly as well.

I'm going to completely remove my drivers and re-install and see if that helps the GPU crashing problem. Regardless though, even when the GPU setting is enabled, the app is painful to use.

Happy to provide any information to help fix this problem as I'm actively pursuing other apps to replace Lightroom much to my displeasure. It's an amazing app if performed well.
Photo of Mihael Tominšek

Mihael Tominšek

  • 37 Posts
  • 31 Reply Likes
How come developers of Lr does not "see" all the problems? Even computer geeks should see that real life usage of Lr sucks. 
Photo of Art M.

Art M.

  • 87 Posts
  • 18 Reply Likes
I think that some users and apparently ALL the developers never stress the system with heavily edited photographs or needing to cull a lot of images quickly.   So the performance problems of Lightroom are well known in general in the user community, but it's a great secret to the developers who still believe that it's a system by system issue. 
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 5994 Posts
  • 1320 Reply Likes
Another question for the group - Windows Users: are any/all of you actively using Windows Defender as your security software? 

Other Windows and Mac users: Security software in use?
Photo of Matt Quinn

Matt Quinn

  • 6 Posts
  • 5 Reply Likes
Windows defender is the only security software I'm using.
Photo of Simon Ringsmuth

Simon Ringsmuth

  • 4 Posts
  • 4 Reply Likes
No security software in use other than what's built in to Mac OS.
Photo of Denyer Ec

Denyer Ec

  • 55 Posts
  • 43 Reply Likes
Windows Defender here.
Photo of Jordan Hofker

Jordan Hofker

  • 1 Post
  • 0 Reply Likes
Just Defender.
Photo of Seb

Seb

  • 10 Posts
  • 6 Reply Likes
Defender turned off, using Avira.
Photo of Matthew George

Matthew George

  • 24 Posts
  • 9 Reply Likes
All I've got running constantly is Windows Defender, and I occasionally run MalwareBytes, but never leave it running in the background.
Photo of Jerry Syder

Jerry Syder

  • 329 Posts
  • 147 Reply Likes
Kaspersky here. Defender off. 
Photo of Alex Furer

Alex Furer

  • 167 Posts
  • 44 Reply Likes
Same as Matthew. Defender and occasionally MalwarBytes.
Photo of Conrad Allan

Conrad Allan

  • 9 Posts
  • 5 Reply Likes
Having the same problem (will write a post below) 

- Only using windows defender
Photo of Joel Weisbrod

Joel Weisbrod

  • 198 Posts
  • 117 Reply Likes
Using Bitdefender on Win 10 x64
Photo of Chris Bartow

Chris Bartow

  • 11 Posts
  • 3 Reply Likes
I downgraded the specs on my new computer to be more portable and there is no difference to any of the performance issues I had with a faster computer.  Meaning more hardware does not help the issues.
The GPU checkbox makes using brushes/editing an individual photo faster, but there is a delay going between images. As someone that does exposure/white balance adjusts to 90%+ of my images I leave this off to make my experience faster.  Wish this could be fixed so I can have both ways fast.
Photo of Mike S

Mike S

  • 38 Posts
  • 13 Reply Likes
I just posted some very good results I got combining a patch posted by Simon Chen, along with affinity masking posted by John Ellis, over on the other Lightroom-is-really-slow thread (https://feedback.photoshop.com/photoshop_family/topics/lightroom-clone-and-brush-tool-can-not-stress...).  I suspect the answer will vary for different chipsets and different tasks, but I'm hoping that Adobe is getting closer to figuring out the problems in multi-core implementations.
Photo of Denyer Ec

Denyer Ec

  • 55 Posts
  • 43 Reply Likes
Is this compatible with Windows?  I'll have to look into it tomorrow as it looks like a promising short-term bandaid.
Photo of Mike S

Mike S

  • 38 Posts
  • 13 Reply Likes
Yes -- I'm running Windows 7.  Basically, you add a config.lua file to your Lightroom folder as described by Simon Chen.  Then you open a cmd window, where you can start Lightroom with (in my case) half my processors turned off.  Performance was dramatically improved.  I haven't done a long editing session yet, so I'll add more performance commentary later. 
Photo of seanhoyt-dot-art

seanhoyt-dot-art

  • 340 Posts
  • 55 Reply Likes
WOW. LR is way faster with the config. I'm 4790K i7 (oc'd) with 32GB of oc'd ram and 280x GPU on mac sierra. 4k monitor, GPU enabled, Smart Preview edit enabled. 
(Edited)
Photo of Denyer Ec

Denyer Ec

  • 55 Posts
  • 43 Reply Likes
I put it here: \AppData\Roaming\Adobe\Lightroom

How would I verify it's running?
Photo of Mike S

Mike S

  • 38 Posts
  • 13 Reply Likes
Look at your 'System Info" (under the help menu).  You should see a line that says:
Config.lua flags: 
Develop.AdjustMaximumThreadCount = 0.51
Its about a 3rd of the way down, under the 'Installed Plugins'
Photo of Denyer Ec

Denyer Ec

  • 55 Posts
  • 43 Reply Likes
Got it, thanks Mike! I'll see what it looks like...
Photo of Mihael Tominšek

Mihael Tominšek

  • 37 Posts
  • 31 Reply Likes
I just updated nVidia drivers (2 days old). As expected, no real difference. I use now 1:1 previews rather than smart previews and GPU acceleration. Why: 

1:1 gives me exact feel about image, and loading is faster and slight slower slidre response does not weight ower. Than GPU gives me faster zooming, paning, and operation. Still brush (today, I will not speak for tommorow) is not that much slower. 

Zooming and pannig is smooth ONLY in main window. On second monitor GPU does not make any difference and panning is jaggy anyway. 
Photo of Seb

Seb

  • 10 Posts
  • 6 Reply Likes
Must admit that this thread does not surprise me at all. I have a gaming PC that I considered to be high spec some time ago. I was so excited when I was building it, could not wait to start working with LR6.

I was so disappointed.

Had to invest in another software to sort the images as LR was too laggy. Develop module tools are also very laggy - zooming an image, spot removal, brush, you name it. At some point it just lags so much to a point I am not clear if it has crashed. Closing (killing the task in Windows) and re-opening LR helps a bit. This is on a machine with 16GB RAM, Geforce GTX 970, SSD drive. Such a shame. And the number of blog posts and articles I have read about "speeding up LR"... :/
Photo of Mihael Tominšek

Mihael Tominšek

  • 37 Posts
  • 31 Reply Likes
"And the number of blog posts and articles I have read about "speeding up LR"... :/" -> they all say same. Update drivers, increase cache (I have it 99 GB on separate dedicated SSD); optimize catalog, etc. You can not build fast enough machine since Lr does not use resources other than when exporting final images. Sad. 
Photo of Denyer Ec

Denyer Ec

  • 55 Posts
  • 43 Reply Likes
Yeah, I too invested in Photomechanic to filter and tag photos, as LR was simply too slow for the job (Especially considering I'd have to leave it overnight to import!) PhotoMechanic manages to be very, very fast for navigating and organising - but I feel like it shouldn't be a necessary purchase - LR has all the tools one needs, except speed.
Photo of seanhoyt-dot-art

seanhoyt-dot-art

  • 340 Posts
  • 55 Reply Likes
Pro-user, 1M shots through LR since beta. My main issues at the moment with 4790k@4.7G w/32GB and SSD previews+catalog and Smart DNG preview edit enabled are: screen flickers constantly with R9 280x GPU enabled. Sometimes, I get a flicker when I use any sliders where the screen shows the previous edit state then new adjustment then back to previous and then settles on new state. I also get a blacked-out image area which seems to be tied to minimize/maximize app switching. I can kill LR and reload to get the photo space back. GPU does speed up my main slider renderings to screen on my 4k monitor. But, GPU does make the clone/heal tool unbearable.

Those complaining that LR is slow in the Library aren't building 1:1 previews or they are comparing to PM which, I believe, pulls the embedded previews not new previews based on import settings. One of the problems with LR is that you must learn all of the *tricks*. Shouldn't the software be smart enough to guide users to the best performance? Shouldn't rendering pause when the user is interacting with the UI and resume 100% cpu load when the user walks away from the computer (FCPX). Shouldn't the user be able to queue up jobs and pause them? Shouldn't the user be able to choose between precision and performance (Develop mode)? 
Photo of Seb

Seb

  • 10 Posts
  • 6 Reply Likes
Mine is quite slow even with 1:1 previews/smart previews. I would not have a problem with having an option to let LR pull embedded previews as I am mainly using library module to sort and rate my photos right after the shoot.
Photo of Matthew George

Matthew George

  • 24 Posts
  • 9 Reply Likes
I build 1:1 previews (which takes 3+ hours for 1000 RAF files, so long as I don't touch my computer for anything else, set it to Max Performance mode, and let the fan crank full speed the whole time while my CPU sits at 100% like a raging volcano) and it helps a bit with moving from photo to photo to rate and select, but the second I start actually making edits in the develop module, things slow back to a crawl. Adjusting exposures, doing gradient adjustments, or heaven forbid, trying to use the spot-heal brush all take multiple seconds for the results to show up on-screen. 

There are only so many "tricks" and even if they worked, they shouldn't be necessary. Something with nearly the same features (like Capture one) has far less issues when it comes to doing edits with good performance. 
Photo of Simon Ringsmuth

Simon Ringsmuth

  • 4 Posts
  • 4 Reply Likes
I also build 1:1 previews and it barely helps at all with the slowness
Photo of Seb

Seb

  • 10 Posts
  • 6 Reply Likes
I really can't understand why there is such a huge performance difference between PhotoMechanic and LR, even after giving LR 1 hour to generate previews. 

But let's even leave PM. Windows 8 built in photo viewer (I think it's just called "Photos") sweeps through RAW files as fast as PM. Instant. Previews. It does not read xmp files so you cannot see edits in that but who cares when sorting uneditied photos. Perhaps Adobe should allows us to enable that in Library module. Or introduce a new module called "Sort" - ultra fast, minimal interface module for quickly browsing through our images.
Photo of seanhoyt-dot-art

seanhoyt-dot-art

  • 340 Posts
  • 55 Reply Likes
That's impossible. On my machine, with 1:1 in Library, it's nearly instant. There is 0.0% rendering time. I can arrow through shots with no delay. I cull at about 1500/hr. Are you rendering 1:1 and then culling in Develop module?  I'm talking zero delay to a 4k monitor. 
(Edited)
Photo of seanhoyt-dot-art

seanhoyt-dot-art

  • 340 Posts
  • 55 Reply Likes
@Seb - PM is pulling the 1/4-size JPEG preview if you are shooting Canon. So, if 24MP Raw, you are sifting through 6MP heavily-compressed jpeg not 1:1 24 megapixel JPEG. What happens in PM when you zoom 1:1?? (I haven't used PM)
Photo of Denyer Ec

Denyer Ec

  • 55 Posts
  • 43 Reply Likes
It renders - there is a short delay but nothing like LR. Obviously it's not rendering a processing stack, but it's certainly not frustratingly slow.

At 25 images per minute, you must be swapping between them in < 2s. What is your system? I'd kill to be able to do that!
Photo of Matthew George

Matthew George

  • 24 Posts
  • 9 Reply Likes
I've got an i7, 32 gigs of ram, and two really fast SSDs with plenty of free space on them, and Lightroom is the most frustrating program I've ever used in terms of sluggish input and usability. Changes with the adjustment brush, or other mildly complex adjustments take multiple seconds to show up on my screen (which doesn't sound like much, but when you're trying to make 50 adjustments to 400 photos, it REALLY adds up) and just creating 1:1 previews for 1000 RAF files regularly takes me 3+ hours. 

I've got all my drivers up to date, I've got the most recent version of Lightroom CC, and I've spent 3 hours with an Adobe rep directly controlling my computer trying to optimize my settings with no benefit at all.

I HATE using Lightroom, and if I could afford to use both Lightroom/Photoshop and Capture One, I would absolutely do it. 
Photo of Seb

Seb

  • 10 Posts
  • 6 Reply Likes
Not to be funny but issues that users are describing are not just relevant for LR 2015.10. I, at least, am experiencing those issues since I can remember. Always thought my machine was too slow, until I upgraded.
(Edited)
Photo of Matthew George

Matthew George

  • 24 Posts
  • 9 Reply Likes
I'm very jealous. What camera are you using, and what sorts of editing do you do? 
Photo of Seb

Seb

  • 10 Posts
  • 6 Reply Likes
What I am trying to say is that I always thought that my machine was too slow, upgraded and realised it is LR, not my machine.
(Edited)
Photo of Matthew George

Matthew George

  • 24 Posts
  • 9 Reply Likes
I see. Well, I have a fairly monstrous system, with an overclocked i7 processor, 32Gigs of very fast ram, and some extremely quick SSDs, and a huge cache, and I have tons of issues, so if the answer is "buy a better computer" then I'm going to need to win some sort of lottery to be able to afford a better setup than I've currently got. 
Photo of Seb

Seb

  • 10 Posts
  • 6 Reply Likes
Agree 100%. Like others have said in this thread - you cannot build a computer fast enough to handle LR well.
By the way, I run an overclocked i5-2500k, 16GB RAM, GTX 970, SSD. Cache set to 20GB.
(Edited)
Photo of Mike S

Mike S

  • 38 Posts
  • 13 Reply Likes
Matthew, Seb -- how many CPU's are you running?  There's a significant issue in LR where adding cores actually destroys performance.  I posted some test data and the way I'm planning to run over on this thread: https://feedback.photoshop.com/photoshop_family/topics/lightroom-clone-and-brush-tool-can-not-stress...
Don't know if it will help you, but having read every "speed up lightroom" thread out there, this is the first time I've found anything that makes a difference.
Photo of Matthew George

Matthew George

  • 24 Posts
  • 9 Reply Likes
Mike, my i7-4800MQ has 4 cores and "8 Logical processors" according to my task manager. I'll follow your link and do some reading. 
Photo of Denyer Ec

Denyer Ec

  • 55 Posts
  • 43 Reply Likes
That's just the thing though guys - some people out there (With inferior specs, or Macs) don't exhibit these symptoms. It would be a no brainer to blame straight Lightroom for the delays, but as some people don't experience them, it's got to be Lightroom in conjunction with something that's causing the terrible performance.
Photo of Seb

Seb

  • 10 Posts
  • 6 Reply Likes
Thanks Mike, did the config.lue patch but cannot see any difference.

Denyer, I am not saying it is just Lightroom but since it's Adobe's product, they should be identifying what it is that's causing issues.
Photo of Art M.

Art M.

  • 87 Posts
  • 18 Reply Likes
The difference could be the functions that people are using.  The primary delays I experience are in D mode on photographs that have had a number of brush/clone/heal actions.  If someone does not do a lot of that type of editing then they might be fine in D mode.  

As for the slowdowns in G mode scrolling through photographs that lack 1-1 previews, perhaps those who don't experience the problem are shooting smaller numbers of photographs per shoot?
Photo of Matthew George

Matthew George

  • 24 Posts
  • 9 Reply Likes
Mike S - it looks like I'm running the same processor as you, so I'm hoping to get the same results you got, but I'm struggling with getting the Config file to take effect in my Lightroom installation. My Flags stay at "none" in system Info. I'm thinking my "Show Lightroom Presets Folder" might not be taking me to the correct folder. 
Photo of Mike S

Mike S

  • 38 Posts
  • 13 Reply Likes
Matthew -- Mine took me to C:\Users\{your name}\AppData\Roaming\Adobe, and I dropped the config.lua file into the Lightroom folder (so inside C:\Users\{your name}\AppData\Roaming\Adobe\Lightroom.
Photo of Mike S

Mike S

  • 38 Posts
  • 13 Reply Likes
Matthew -- Mine took me to C:\Users\{your name}\AppData\Roaming\Adobe, and I dropped the config.lua file into the Lightroom folder (so inside C:\Users\{your name}\AppData\Roaming\Adobe\Lightroom.
Photo of Mike S

Mike S

  • 38 Posts
  • 13 Reply Likes
Sean -- How many cores are you running, and did you also change affinity (from a cmd window -- can't do it after the process starts running).  I didn't get much improvement from the config.lua file by itself -- it was the combination of that plus the affinity change.  Also, did you verify that you had the config.lua file actually running (see it in system info)?  If you have a multi-core system that doesn't benefit at all from those two changes, it just highlights why Adobe is having so much trouble figuring this out.
Photo of Seb

Seb

  • 10 Posts
  • 6 Reply Likes
Dropping the file in the presets folder did not work for me either as I have LR set up to store presets with catalog. However, it did work when I copied it into: 
C:\Program Files\Adobe\Adobe Lightroom
Photo of Mike S

Mike S

  • 38 Posts
  • 13 Reply Likes
Seb -- meant to address the above to you, not Sean, based on you saying that config.lua didn't help:

Seb -- How many cores are you running, and did you also change affinity (from a cmd window -- can't do it after the process starts running).  I didn't get much improvement from the config.lua file by itself -- it was the combination of that plus the affinity change.  Also, did you verify that you had the config.lua file actually running (see it in system info)?  If you have a multi-core system that doesn't benefit at all from those two changes, it just highlights why Adobe is having so much trouble figuring this out.
Photo of Seb

Seb

  • 10 Posts
  • 6 Reply Likes
I am running 4 cores.
Yes, I did check sys info in LR and it stated = 0.51 under config.lua flags.
I only did the config patch without anything else but will try the rest as well.

I do appreciate that if it would be easy to figure out, they would have fixed it by now. So what does the affinity do exactly? 
Is it a matter of executing "/affinity F cmd.exe /c "c:\Program Files\Adobe\Adobe Lightroom\lightroom.exe" in Windows run?
(Edited)
Photo of Mike S

Mike S

  • 38 Posts
  • 13 Reply Likes
Seb -- on a 4 core system, you may want to try a mask of '3' or '5' (to get to 2 core usage) rather than 'F' or '55'.  I found the best results when I cut my core usage in half.  Of course, that's just my anecdotal result.  Perhaps Adobe will weigh in on this at some point with something more systematic.
Photo of Matthew George

Matthew George

  • 24 Posts
  • 9 Reply Likes
Mike and Seb, thanks for the the tip about putting it into the Lightroom folder. That did it for me.

Mike, do you have more details on the additional Affinity change? I can't seem to find any information about that, and I don't know what it's referring to. 
Photo of Mike S

Mike S

  • 38 Posts
  • 13 Reply Likes
https://feedback.photoshop.com/photoshop_family/topics/lightroom-clone-and-brush-tool-can-not-stress...

Search the page for 'Ellis' -- the first time he pops up, he describes the procedure to start Lightroom with certain processors turned off (known as setting affinity)
Photo of Matthew George

Matthew George

  • 24 Posts
  • 9 Reply Likes
Thanks Mike.

I did both steps, and then went and cleared out 1:1 previews for 775 photos, and then started rebuilding them. Before these changes, it would spike to 100% CPU usage and take forever. Now, I'm staying around 50% CPU usage (Makes sense since I told it to use only half my cores) and while it's still seeming to take a while, the system is at least running a bit cooler. 
Photo of Mike S

Mike S

  • 38 Posts
  • 13 Reply Likes
I didn't do any benchmarking on building previews -- just in the develop module.  But its worth timing the operation, then repeating it under 'normal' conditions, just to satisfy yourself that there's real improvement or not.  I'm definitely curious about what you find.
Photo of Art M.

Art M.

  • 88 Posts
  • 18 Reply Likes
Is there a way for me to receive a single daily digest email of this conversation rather than getting a separate email for every single comment?   I'd like to track this conversation but getting all theses emails is too tedious.  Thank you.
Photo of Mihael Tominšek

Mihael Tominšek

  • 37 Posts
  • 31 Reply Likes
And you just got email that I liked your comment and separate email for this peace of writing. :(
Photo of Mihael Tominšek

Mihael Tominšek

  • 37 Posts
  • 31 Reply Likes
Guys... I have enough. We are dancing rainmaking ritual here, since we all know it will not be any different, but we perform it anyway out of desperation. Until Adobe will fixed it (or someone else). I'm cured for next few jobs from temptation to waste 10's of hours seeking nonexisting solution on desperate users's forum. 

This afinity is nonsense. I excluded half of my logical cores (so 6 instead of 12) and it just goes slower. For editing it is not much of a difference. But for creating prewiews significant. I can tell my system is fast since importing and creating previrew are really fast. Exporting as well. Just editing. And NO, I do not mean how fast image renders (that too), but I hate that sliders that used to be smooth and real time are now choppy, sticky, laggy and during changes image got blurred, panels or sliders or part of images goes blank, and so on.


Yes, developers probably load handfull of images and try them. Fine, if you trying image per se. But culling on Lightroom is not an option anymoore. You nned to switch images fast, zoom in zoom out, decide which is which, maybe make simple exposure adjustment. Sure, creating 1:1 previews helps here. But still... c'mon, we are paying a lot.   
Photo of Robert Frost

Robert Frost

  • 426 Posts
  • 73 Reply Likes

With your sliders problem, my guess is that it is a graphics driver problem. Are you using the latest graphics update? Try a different graphics card - I had a LR problem years ago with a Radeon card that was cured by switching to a NVidia card. I now use a NVidia quadro since they are more reliable than gaming cards. If you can't afford a new graphics card, borrow one for a test. Poor graphics drivers can cause all sorts of problems - just look at the list of problems listed in the manufacturers info for each graphics card/driver (some games will work, others won't, and this list changes for each update).

Bob frost 

Photo of Steve Gandy

Steve Gandy

  • 119 Posts
  • 37 Reply Likes
Could this be why we don't see any Mac users complaining here? Perhaps Adobe needs to certify graphics hardware for this important software.
Photo of Jose Mondia

Jose Mondia

  • 7 Posts
  • 7 Reply Likes
I have tried both nvidia and amd gpus and the performance is still crap. Also tried disabling GPU in LR and same crappy result. I've seen a lot of complaints from Mac users in the web as well so no, this is not isolated to PC crowd. Download a trial of capture one pro and you will see how a properly engineered software runs. I am not sure how much longer I can tolerate LR before I jump ship.
Photo of Steve Gandy

Steve Gandy

  • 119 Posts
  • 37 Reply Likes
The only lags I really see is when I'm culling and need to fly through a lot of images. I have recently bought FastRawViewer for a pittance. It displays RAW files very fast, lets you tag with colors and/or stars that Lr reads from the XMP. I suggested in another post (https://feedback.photoshop.com/photoshop_family/topics/module-suggestion-organize) that Lr needed a more fully featured organization mode but perhaps part of that should be a culling mode as well. Good luck with the sliders and so on. I don't see that at all.
Photo of avpman

avpman

  • 125 Posts
  • 91 Reply Likes
Out of curiosity, what viewer did you get? Do you copy the files to another folder first after culling and then import to LR?
Photo of Steve Gandy

Steve Gandy

  • 119 Posts
  • 37 Reply Likes
It is called FastRawViewer at fastrawviewer.com. I'm still experimenting with the workflow but you can either;
  •  import thru Lr then switch to FRV, rate, label and cull, then tell Lr to synchronize the folder or
  • bring the images into a folder without Lr, do all the culling then import the folder into Lr
So far, I like to start with Lr as I prefer to rename the files, add metadata easily etc. but if I was in a hurry I would just use the viewer and worry about the Lr stuff later.
Photo of Jerry Syder

Jerry Syder

  • 287 Posts
  • 139 Reply Likes
Steve, is it notably faster when culling? I saw this video where they compare the histogram information that we get from Adobe vs this their histogram where it's reading 100% RAW data instead of the JPEG preview data that Lightroom reads and subsequently produces https://www.youtube.com/watch?v=6xWHaSz_KDM&t=378s
Photo of Steve Gandy

Steve Gandy

  • 119 Posts
  • 37 Reply Likes
I think it is. I notice some lag time when popping through the images in Lr but almost none in this viewer. However, I'm not really using all the features or worrying about the histogram and so on. When culling I just want to see a screen sized image to evaluate basic exposure, focus and composition.
Photo of Rich Soublet

Rich Soublet

  • 1 Post
  • 1 Reply Like
Just wanted to chime in that sliders are sticky and laggy for me too. Importing and exporting are fine and quick. Image render is quick. But sliders stick and lag. I don't use the brush much as I use photoshop for my fine tuning. Photoshop runs like a dream but Lightroom is slow as molasses.