Experiencing performance related issues in Lightroom 4.x

[BCormier]

Anyone else notice that lightroom 4 is slow? Ligtroom 3 always ran fast on my system but Lightroom 4 seemlingly lags quite a bit.

My system is:

2.10 ghz Intel Core i3 Sandy Bridge

8 GB Ram

640 GB Hard Drive

Windows 7 Home Premium 64 Bit

Message title was edited by: Brett N

[kwdaves]

PV2012 with Sony .arw files- I see a .dat file being created, but only when I scroll from one image to another in either the Library or Develop Modules.

[Chris GC]

That's exactly right. Raw (DNG converted). I tried this with adjacent files - edited ones in PV 2010 (imported in LR 3) then updated several similar adjacent files to pv2012 using the selected photo option (so they were not selected whilst still as PV 2010). The updated files do not then create a file in the cache folder when selected in develop. All new files imported into LR 4 with PV 2012 do not seem to create a cache file. It was easy to see this once the cache was purged.

[areohbee]

Chris GC wrote:

Raw (DNG converted).

I heard @Lr4+DNG (with fast-load enabled, which is the default I believe) cache data is stored in DNG file instead of separate file in cache folder. Could be just a rumor, but that's what I heard (don't use DNG m'self).

?

[Cornelia-I]

That is at least what Victoria Bampton writes into her "Missing FAQs": For DNGs, with "Embed Fast Load Data" set, there are no ACR cache entries (page 347).

I have that setting enabled and convert all my proprietary raw files to DNG during import.

What keeps me wondering though is that from a 292-images import of today (hence all native PV2012) my cache got 7 entries.

This is very strange, as I would expect 0.

The number does not fit with anything else:

I have culled 35 images after first walk-through, some after trying develop edits before deciding they are not worth their storage space. Culled= removed from catalog and deleted from disk.

I have made develop adjustments to 109 of the remaining images.

But I am one of the lucky ones without performance glitches (still on LR4.0, Win7-64bit, i7, 8GB RAM, NVidia).

Testing integrity should be a default part of every LR-backup. But this does not solve anything, whereas a mysterious trigger for integrity check did it?

Cornelia

[areohbee]

Cornelia-I wrote:

This is very strange, as I would expect 0.

Me too.

I can imagine the code:

Wait x milliseconds for process y to complete. If successful, be happy, if unsuccessful, be quiet, but write a cache entry, and hope it can be used if problem z presents again next time...

I'm a software "engineer" too .

Rob

[Sam Breach]

I have an iMac with 16GB of Ram. I started a virgin LR catalog with LR4 and it still is under 3k photos. I have a SSDrive for both my LR catalog and pictures. It has so far taken me over 4 hours to download 500 photos. It seems to me like there is something seriously wrong with this programme. I think I am going to have to go back to LR3. I am still trying to read through this giant thread to see if there is a solution, but in the meantime just thought I would record that I am having issues so that Adobe can see there is yet another person struggling with their software. I had no such issues, ever, with LR3.

[areohbee]

I had major issues with early Lr3, only more minor issues with Lr4 so far.

Honestly, I think the lazy human's approach to this problem makes the most sense for the most people:

Use Lr3 instead, until Lr4 works well enough for you.

On the other hand, if you are bright and energetic, with good technical skills, you probably can get it to work better, probably before Adobe does, but it will probably take a lot of effort...

PS - I tried Aperture when I was exasperated with Lr3 early on - Aperture ran so slow it was unusable (develop adjustments would take several seconds to *minutes* to sink in, if it didn't crash the machine - go figure: virgin Apple Mac, up-2-spec, up-2-date, running all Apple software... - 'tis a puzzlement...

I struggled with Lr3 instead, cursing regularly, until Adobe (& me) remedied (could've continued with Lr2 instead, but Lr3 wasn't *that* bad...). If Aperture had worked correctly for me, I may be telling this story on a different forum ;-} and, be using a different OS (I was ready to switch to Mac, Lr3 was *that* bad). Still on Windows now...

Lr4 rocks! (although not perfectly, not by a long shot, even for lucky ol' me...).

Cheers,

Rob

[BKKDon]

Hi,

Maybe it may help to say what configurations actually work. I have a VAIO Desktop with 8Gb of memory, Intel i7 x 2 Quad processors, 1 TB Disk, NVIDIA with 1Gb etc I think it is a VPCL218FG/B model and it works very well, extremly fast.

The other I have is a HP Laptop (old HP-DV4) with 500Gb hard disk as a field machine which takes 14 secs initially to load LR4 and then about 8 secs to switch to develop module the first time but after that all is ok - the info from LR is:

Lightroom version: 4.1 RC 2 [825534]

Operating system: Windows 7 Home Premium Edition, Version: 6.1 [7601]

Application architecture: x64, System architecture: x64

Physical processor count: 2. Processor speed: 2.5 GHz (I think i5 Centrino 2)

Built-in memory: 4062.9 MB

Real memory available to Lightroom: 4062.9 MB

Real memory used by Lightroom: 473.4 MB (11.6%)

Virtual memory used by Lightroom: 462.5 MB

Memory cache size: 302.8 MB

Displays: 1) 1280x768, Adapter #1: GeForce 9200M, Video Memory : 493

I guess the only thing I do with my workflow is import CR2 files, reject those I don't want and then convert to DNG before developing.

I hope this can help.

[areohbee]

Unfortunately, even apparently equivalent configurations can work for some and not for others, as evidenced by people using vanilla Macs (that goes for Aperture too, not just Lightroom).

That said, I'm having "relatively" good luck with:

-----------------------------------------------------------

Lightroom version: 4.1 RC 2 [825534]

Operating system: Windows 7 Ultimate Edition

Version: 6.1 [7601]

Application architecture: x64

System architecture: x64

Physical processor count: 4

Processor speed: 3.4 GHz

Built-in memory: 7934.1 MB

Real memory available to Lightroom: 7934.1 MB

Real memory used by Lightroom: 728.9 MB (9.1%)

Virtual memory used by Lightroom: 890.5 MB

Memory cache size: 191.3 MB

System DPI setting: 96 DPI

Desktop composition enabled: Yes

Displays: 1) 1920x1200, 2) 1920x1200

Adapter #1: Vendor : 1002

    Device : 9714

    Subsystem : 84541043

    Revision : 0

    Video Memory : 355

AudioDeviceIOBlockSize: 1024

AudioDeviceName: Digital Audio (S/PDIF) (High Definition Audio Device)

AudioDeviceNumberOfChannels: 2

AudioDeviceSampleRate: 44100

Build: Uninitialized

Direct2DEnabled: false

GL_ALPHA_BITS: 8

GL_BLUE_BITS: 8

GL_GREEN_BITS: 8

GL_MAX_3D_TEXTURE_SIZE: 8192

GL_MAX_TEXTURE_SIZE: 8192

GL_MAX_TEXTURE_UNITS: 8

GL_MAX_VIEWPORT_DIMS: 8192,8192

GL_RED_BITS: 8

GL_RENDERER: ATI Radeon HD 4290

GL_SHADING_LANGUAGE_VERSION: 3.30

GL_VENDOR: ATI Technologies Inc.

GL_VERSION: 3.3.10524 Compatibility Profile Context

OGLEnabled: true

OGLPresent: true

GL_EXTENSIONS: GL_AMDX_debug_output GL_AMD_conservative_depth GL_AMD_debug_output GL_AMD_depth_clamp_separate GL_AMD_draw_buffers_blend GL_AMD_name_gen_delete GL_AMD_performance_monitor GL_AMD_sample_positions GL_AMD_shader_stencil_export GL_ARB_ES2_compatibility GL_ARB_blend_func_extended GL_ARB_color_buffer_float GL_ARB_copy_buffer GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_draw_buffers_blend GL_ARB_draw_elements_base_vertex GL_ARB_draw_instanced GL_ARB_explicit_attrib_location GL_ARB_fragment_coord_conventions GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_geometry_shader4 GL_ARB_get_program_binary GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_imaging GL_ARB_instanced_arrays GL_ARB_map_buffer_range GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_occlusion_query2 GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_provoking_vertex GL_ARB_sampler_objects GL_ARB_seamless_cube_map GL_ARB_separate_shader_objects GL_ARB_shader_bit_encoding GL_ARB_shader_objects GL_ARB_shader_precision GL_ARB_shader_stencil_export GL_ARB_shader_texture_lod GL_ARB_shading_language_100 GL_ARB_shadow GL_ARB_shadow_ambient GL_ARB_sync GL_ARB_texture_border_clamp GL_ARB_texture_buffer_object GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_compression GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map 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_mirrored_repeat GL_ARB_texture_multisample GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_texture_rgb10_a2ui GL_ARB_texture_snorm GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_transpose_matrix GL_ARB_uniform_buffer_object GL_ARB_vertex_array_bgra GL_ARB_vertex_array_object GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_ARB_window_pos GL_ATI_draw_buffers GL_ATI_envmap_bumpmap GL_ATI_fragment_shader GL_ATI_meminfo GL_ATI_separate_stencil GL_ATI_texture_compression_3dc GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_ATI_texture_mirror_once 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_copy_buffer GL_EXT_copy_texture 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_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_histogram 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_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texgen_reflection GL_EXT_texture3D GL_EXT_texture_array GL_EXT_texture_buffer_object 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_add 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_rectangle GL_EXT_texture_sRGB GL_EXT_texture_shared_exponent GL_EXT_texture_snorm GL_EXT_texture_swizzle GL_EXT_timer_query GL_EXT_transform_feedback GL_EXT_vertex_array GL_EXT_vertex_array_bgra GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_conditional_render GL_NV_copy_depth_to_color GL_NV_explicit_multisample GL_NV_float_buffer GL_NV_half_float GL_NV_primitive_restart GL_NV_texgen_reflection GL_NV_texture_barrier GL_SGIS_generate_mipmap GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SUN_multi_draw_arrays GL_WIN_swap_hint WGL_EXT_swap_control

-----------------------------------------------------------

That's mainboard graphics and audio.

- Develop module is usually very responsive, although Lr still crashes sometimes, especially when using FTP-ing plugins on an iffy comm link.

(usually "before / after" is nearly instantaneous, but sometimes it will take several seconds - when it's in a mood. straightens itself out eventually...)

Still takes a while to load images, like Lr3 did, but once loaded, is responsive.

Library seems about the same as Lr3 was - fast, as long as previews are there.

Some plugins run much faster, due to a bug in Lightroom multi-tasking that was fixed in Lr4b - yippee!

Plugin ops often can not be run on whole catalog, and require division into smaller photo sets to avoid excessive memory consumption.

Cheers,

Rob

[fliplip1]

As a follow on to some of the hardware comments recently, i for one dont regret changing the MoBo and CPU one bit. I know its not the real solution to getting LR4 running up to speed but im happy it gave me an excuse to upgrade. After 3 years with a mid range dual core it was time to make the jump anyway. I would never had done it if my PC was newer. Everything i working much smoother and faster.

For what its worth i was seeing both cores of my old AMD CPU max out at 100% almost every time i hit a slider, and for the whole duration of exporting images. Now im seeing around 10-30% bursts.

I have use of 4 PC's, 3 at work and my home one. All are running i5's of some flavour, 3 are using the OB graphics output, mine is running a ATI 6770 GPU and all are running LR4 fine.

None of the catalogues were updated from 3.6, they were all started fresh with LR4.0, all running Windows 7 64 bit, 4GB ram minimum.

[Guest]

Sam Breach wrote:

I have an iMac with 16GB of Ram. I started a virgin LR catalog with LR4 and it still is under 3k photos. I have a SSDrive for both my LR catalog and pictures. It has so far taken me over 4 hours to download 500 photos. It seems to me like there is something seriously wrong with this programme. I think I am going to have to go back to LR3. I am still trying to read through this giant thread to see if there is a solution, but in the meantime just thought I would record that I am having issues so that Adobe can see there is yet another person struggling with their software. I had no such issues, ever, with LR3.

Sam, on a side note, (because I gave up a long time ago on LR 4 or Adobe fixing it soon). I would recommend to have at least your photos on an "old fashion" HD and not on an SSD. It is true that SSD are faster but if they fail, you won't be able to recover your photos. With the normal HDDs, you can still recover your photos (in most cases).

If you backup to a RAID of normal HDDs then disregard this comment.

[glugglug]

A disk fails and you lose your photos? Seriously, anyone to whom that happens deserves. it. Anyone who doesn't have a couple of up to date backups of their work is lazy, an idiot or both. You have years of photos and you would  risk them all for the sake of a few minutes setting up a backup?  Backups can be automated and immediate if you wish, thus no trouble or effort at all.

There is an IT  saying: There are two types of computer user. Those who have just lost all their data and those who are just about to.

Message was edited by: glugglug/ Typo

[fliplip1]

Haha, im not dissagreeing with the back up bit but IME IT workers can often talk a load of BS.

[J_Chin_Photography]

I just went into my LR41rc2 and made a crop adjustment to an unedited photo, my CameraRaw cache was updated, I see a DAT file with a current timestamp.  Are you looking in the correct folder?  I had moved my CameraRaw cache in LR3 and when I setup LR4, I forgot that I did that and the new LR4 catalog used a CameraRaw cache in its default location (in C:\Users\...\AppData\Local\Adobe\...)..

[Chris GC]

Thanks for trying this, I have the correct folder - I can see the dat files being created for the PV 2010 files. I purged the cache again and opened several PV2012 files - nothing created at all in the cache folder. I then go to some old pv 2010 files and immediately upon selecting these in develop module the dat file is created together with the index.dat file. Then tried opening PV 2012 files - nothing created.

I moved my Cache folder to a seperate hard disk to where I keep my photos and lightroom - to kee the back up disk image size down.

[kwdaves]

Try switching to another image or switching to the library module. i think the .dat file is being created for an image when you deselect it or switch to the library

[J_Chin_Photography]

Try chaning the cache folder location and see if it creates new files in the new folder.  Mine seems to be working just fine with newly imported images in LR41rc2; slow in Develop module still but at least it is working.

[Chris GC]

I have just put the cache folder back to the default - and the same situation exists - no cache files for PV 2012 edited files - or new files imported into LR4 with PV2012. But working fine for the PV2010 files.

[Lee_Jay]

Chris GC wrote:

I have just put the cache folder back to the default - and the same situation exists - no cache files for PV 2012 edited files - or new files imported into LR4 with PV2012. But working fine for the PV2010 files.

I can't reproduce this.  No matter what I do, I get new cache files with either PV.

[Chris GC]

Lee Jay wrote:

Chris GC wrote:

I have just put the cache folder back to the default - and the same situation exists - no cache files for PV 2012 edited files - or new files imported into LR4 with PV2012. But working fine for the PV2010 files.

I can't reproduce this.  No matter what I do, I get new cache files with either PV.

Lee Jay

Thanks very much for trying. - I thought I was on to something. I have just imported some new photos into lightroom and cannot get any cache files generated for them. However I have explored what happens when old files are updated to PV 2012 - since moving the cache location to the default location and then back to my original position it is now creating cache files for updated photos from PV 2010 to PV 2012 which it was not doing before, it - but not for files imported with PV 2012 assigned. Not sure what's going on.

So I now get cache files for PV2010 and files converted from PV 2010 to PV 21012.

But no cache files for original PV 2012 versions no matter what I do.

[howintheworld]

I have the same "problem": an empty cache folder. Whatever I try, my cache stays empty. It is true that I convert my raw files to DNG's on import. Gonna do the test with some jpeg's and see if they leave a trace in the cache folder.

EDIT just tried with a jpeg file: added a few modifications in develop mode, went back to library module: still an empty cache folder.

Jos

[howintheworld]

Another thing I noticed is that when clicking PURGE video cache, there is a message coming up confirming the cache is purged. When I try the same thing with the camera raw cache, there is no message at all. I reverted to the original cache folder, which is still filled wit more then 7 gig of data from 2011, I clicked PURGE cache and nothing happens. All the data remains where it is. So it seems that in my case Lightroom 4 RC2 cannot or will not write nor read nor purge the cache folder.

Jos

[jeremyjp]

Lightroom 4.0 and 4.1 RC2 were unusable on my desktop. Worked much better on my laptop while mobile and I was blaming my mega catalog.

After reading some posts in this thread, I just went through and performed the following changes on Windows 7 x64, Lightroom 4 RC2 x64.

- File - Optimize Catalog

- Exited Lightroom, browsed to my camera raw cache folder which was moved to another HDD, and found it was completely empty

- Emptied all recycle bins for all drives

- Relaunched Lightroom, chose PURGE CACHE again

- Changed Camera Raw Back to the OS disk, although not in the default location (c:\camerarawcache)

- Purged cache again

- Relaunched Lightroom

- Goggled at how much faster things are. Lightroom is usable again!

The steps above aren't a suggestion for exactly how to fix it but are just all the steps I took. I suspect purging and moving the cache was the key, possibly back to same base disk as Lightroom is running from?

Either way, Lightroom is now usable again. We'll see how long it lasts for, but for now I'm happy.

[Chris GC]

howintheworld wrote:

I have the same "problem": an empty cache folder. Whatever I try, my cache stays empty. It is true that I convert my raw files to DNG's on import. Gonna do the test with some jpeg's and see if they leave a trace in the cache folder.

EDIT just tried with a jpeg file: added a few modifications in develop mode, went back to library module: still an empty cache folder.

Jos

It seems as stated my some others that the new DNG file incorperates the cache file - so no cache file is generated in the camera raw cache folder. I found an Adobe TV presentation by Julieanne Kost in which she described the function within the new dng format. The link is:

http://tv.adobe.com/watch/whats-new-in-lightroom-4/dng-enhancements/

In this presentation she says the file should load faster using DNG rather than the camera raw cache file in develop - up to 8 times faster. My simple tests do not support this increase in loading time. Selecting PV 2010 files show that the second and subsequent times the file is selected the screen loads straight away. The PV 2012 takes a couple of seconds on my system with the Loading... status shown - even with selecting the file straight away several times. I wonder if this use of the embedded preview file for develop module is part of the cause of the slow down for some peoples - if the are converting to DNG and using PV 2012. I know people are looking at the computer set up - but it would be interesting to see if it was more a point of whether people are converting to the new dng format.

Some of you are more experienced than me but could a possibility be a problem with this new dng format used by some people rather than their system?? Not sure whether people have declared this when stating they have a problem.

I have tried importing raw canon cr2 files alongside the dng files. Strangely a camera raw cache file is created in the cache folder on import - not just when going into develop module - but a cache file is created under PV 2012 - it seems to be the dng file that is different as suggested.

My sysem is Ok for LR 4 certainly useable but a bit slow at times for editing - not consistently so but annoyingly so at times.

I have an intel quad core running at 3.3ghz, 8gb ram, 64bit windows 7 and UDMA  mode 5 (ATA/100) hard disc for my photos and catalog (27k of photos) and a similar seperate hard disc for my photo back up and camera raw cache. I do quite a lot of video editing and rendering without problems on this system.

Lightroom version: 4.1 RC 2 [825534]
Operating system: Windows 7 Business Edition
Version: 6.1 [7601]
Application architecture: x64
System architecture: x64
Physical processor count: 4
Processor speed: 3.3 GHz
Built-in memory: 8191.0 MB
Real memory available to Lightroom: 8191.0 MB
Real memory used by Lightroom: 1257.3 MB (15.3%)
Virtual memory used by Lightroom: 1322.8 MB
Memory cache size: 1433.3 MB
System DPI setting: 96 DPI
Desktop composition enabled: Yes
Displays: 1) 1680x1050

Application folder: C:\Program Files\Adobe\Adobe Photoshop Lightroom 4 RC2
Library Path: G:\Lightroom\Lightroom Catalog 1 (Main)\Lightroom Catalog 1 (Main).lrcat
Settings Folder: C:\Users\Chris\AppData\Roaming\Adobe\Lightroom

[howintheworld]

Yes, you are right. When I resave an image as DNG without the new option to embed fast load data, and I treat that image in the develop module, a dat file is created in the camera raw cache. I have to admit however that the image with the new fast load data embedded is not one split of a second faster than the image without it, at least that's the case on my computer.

Jos

W7 B64 bits

8 gig RAM