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

[Natsukashi53]

@lynne,

I think it may be due to the file size that you're getting out of the D4. have you tried shooting in mRaw or sRaw? not that it should really make a difference, but that's the only thing that I can think of. also, make sure your software is up to date with camera raw. do a software update in your Lightroom. I believe the d800 an canon5d are the latest updates I've had to download for my Lightroom. maybe that's what's missing on yours? (the latest camera raw updates)

Sent from my iPhone

[LynneHarty]

I looked up software updatesin LR 4 and it says I'm up to date. I DO have a humongous catalog - will this slow me down? I tend to keep most everything in one place.

Lynne

[Robbie2006]

Hi Lynne,

Do you keep your photo's and catalogue on the same drive that your operating system is on.

[LynneHarty]

No I've kept them together in a folder on my Lacie SATA drive.

[MarceloTrad]

Anyone have the RC2 link?

Marcelo Trad

[Geoff the kiwi]

Robbie, just to be clear:

Lightroom has no scratch disk setting, it has a Cache for which the settings are in Preferences.

The default position for the ACR cache is in User files. They can be placed where you want them by changing the Preferences just as the size can be increased.

I hvae never seen or heard of Lr placing the cache anywhere than the default position unless the user has changed it in preferences. Not saying it couldn't happen but does seem strange.

BTW a Cache and a Scratch Disk are two very different things.

[Robbie2006]

Hi Geoff the kiwi,

I put all my photo's and catalogue on a separate hard drive, when I went to preferences to allocate my cache memory I noticed that Adobe had already set up where my cache memory was, I then tried editing and after 3 photo's LR4 started to slow quite dramatically, after a lot of thinking I checked again to see where my cache memory was and discovered that as I said Adobe had allocated my cache memory (thats where LR4 goes to do calculations after it runs out of RAM, I hope this doesn't offend you as I don't know your level of IT skills) to my external hard drive (thats where my photo's and catalogue are) and discovered that Adobe hadn't created a folder for my cache memory, I immediately created a folder on my external hard drive called (this is what Adobe had already put in preferences / file handling) and called it the same as Adobe " Adobe raw cache" and incresed the size to 20 gig, I then started working in LR4 and it ran as quick as LR 3.6, I was on editing photo's next day for 1.5 hours and didn't experience any of the problems I had before ie:- very slow, slider lag, zooming was a waste of time, and going from grid to develop took several seconds. I may have been lucky and your problems could be different to mine but when I thought about it when i was doing several adjustments and my PC ran out of Ram it would have been unable to access my cache because Adobe had forgotten to create a folder in my drive, as I said LR4 is now very fast on my PC and I amd delighted that I can now use the new tools in LR4 without any problems.

Regards

[A_C_G]

Robbie,

My guess is that you were one of the lucky ones with a PC that LR liked - but suffering with a non existing cache.

This afternoon I loaded 200 images on to an internal drive (J) separate from my operating system. I created a cache there and let the 200 images have a new catalogue on the same drive.

IMHO my PC was no better than working with my images, catalogue and cache on the same hard drive (C) as my operating system.

With the folders mentioned above on Drive J there is no way I could pretend it worked like 3.6

Sorry. It did not work for me - but thanks for the idea.

Tony

[sparksdjs]

I've played around with every workaround posted (in addition to my own experiments)  and have not seen any improvements - still lags terribly, exports of processed RAW images as JPEGs takes forever and sucks up CPU and memory.  I just went back and did a comparison with 3.6 - using similar processing on the same set of images, LR4 was using just over 1.1GB of memory and taking from 24-50 secs to export.  LR3.6 was using <500KB and exporting the same images in well under 10 secs.  I'm shelving LR4 for now.  I'm a s/w professional with over 40 yrs experience but trying to work through and around this has tried my patience and I'll just wait on Adobe at this point.

Dave

[JP Hess]

I have been a strong supporter of Lightroom 4 RC2. But yesterday our neighbor came to me asking me to take a picture of their family since they were all home. I loaded 14 NEF files from my D90 into Lightroom 4, and the program just choked. The adjustment brush would work sometimes, other times the whole picture would disappear. Lightroom shut down on me twice, and two other times I had to shut it down and restart in order to continue with my editing. Frustrated, I loaded them in Lightroom 3.6 and all the problems went away.

PV 2012 is definitely better, at least that is what a lot of users are saying. I think it's better to a certain degree because we want it to be better. Yes, I'm sure there are some improvements. But those images that I worked on in Lightroom 3 look just fine. Frankly, I wish I hadn't wasted the money on Lightroom 4. It's doubtful that it will ever perform decently on my Windows 7 32-bit computer. I realize I need a 64-bit computer, and maybe someday I will get one. But since Lightroom 3 functions as well as it does I'm abandoning Lightroom 4.

[bob frost]

There is a lot of rubbish being talked about LRs 'cache memory' that you can move/resize in preferences. So let's get the facts straight. The ACR cache that you can move or resize in Prefs, is a cache of partly-processed raw image files. Every time you render a new raw image, the image goes through a long rendering process. Every time you want a 1:1 view of an image, it has to repeat this rendering. So to speed this up, the ACR cache stores a part-rendered xxxx.dat file, that can be finished off more quickly when you need a 1:1 in future. So if you look at this ACR cache it consists of a xxx.dat file for each raw image you have rendered. I have about 67K of images in my catalog (55K of them are raw files), and 55K of xxx.dat files in my ACR cache (plus an index to them). When you delete a file, the corresponding xxx.dat file is deleted, and when you import a new raw image, a new xxx.dat file is added to the cache.

Originally the xxx.dat files were quite large, and one couldn't have them for all raw images (unless one had a very big HDD to spare). In any case there is a limit on the size of the cache, which has been increased recently. But now with LR3.6 and LR4, the size of these xxx.dat files in the ACR cache has been reduced drastically by compression, so my 55K of xxx.dat files only take up 30 GB (prior to this they would have taken up hundreds of GB. If you can't afford this amount of space for the xxx.dat files, you can limit the size of the ACR cache, and it only keeps the more recent ones up to the limit you specify. When the cache becomes full, the files are replaced on a one in/one out basis.

So the ACR cache has nothing to do with being a scratch file as in Photoshop. There is another temporary 'scratch' file that LR uses, but that is not under your control, and in Windows it is in the usual temporary files folder, and it is deleted on closure of LR.

Bob Frost

[Guest]

Bob Frost:

If you refer to my reference to how my system is built, I do want to clarify that what I said and what I have is:

1- dedicated HD for PS scratch and ACR/LR cache files.

The only advantage I see here, is that first LR (on HD1) software is not competing with the catalogue and photos (Raid HD2) and with the cache'd images (HD3). If that wouldn't make any difference at all. Then whatever files are created deleted in HD3 and HD2 then defragmentation won't affect my images or software drives as much as with having the cache on the same drives. If that wouldn't matter either, then I simply have more space and less clutter on my image drive (Raid HD2) and system files (HD1).

I guess it is pretty clear now.

[Geoff the kiwi]

Lr 4.1RC2 is here.

Lynnne you may want to try the RC as well. How big is your Catalog? It shouldn't make any difference.

BTW I've heard of catalogs with over 250k files that work fine.

[LynneHarty]

Geoff,

My catalog has about 50K images in it. I hate to be dense, but what is the RC?

[Geoff the kiwi]

No problem Lynne, RC is Release Candidate which means that the version is beyond beta stage but could still use more testing. It has improved issues for some not not others. This slowness is weird in who it hits. Personally I haven't had any major issues, the same as most users but those who have been hit seem to get hit hard......

BTW 50k files shouldn't make any difference to performance. Where exactly are you having issues with performance wise?

[LynneHarty]

Oh I didn't there was such a version. I have a shoot in about an hour and am seriously hesitant to use my D4 because of how much longer it takes to process the files in LR compared to the files from my D700. I'm not sure what the issue is there - yes the files are bigger but not THAT much bigger. How do I find the RC?

Lynne

[Geoff the kiwi]

Click the "here" in my post two up!!

Or here !!

[MarceloTrad]

Thanks for the Link!!!

Does anyone knows if Adobe is adressing slowness issues with RC's?

I have RC1 and will instal RC2 and post on any improvements!

Marcelo Trad

[Geoff the kiwi]

MarceloTrad wrote:

Thanks for the Link!!!

Does anyone knows if Adobe is adressing slowness issues with RC's?

I have RC1 and will instal RC2 and post on any improvements!

Marcelo Trad

No, Marcelo the Adobe team have all taken a break after all the fuss.................. kidding!!

For sure there is much work going on in the background taking into consideration all the feedback and buig reports from here and other forums, etc. I would expect it won't be too long before the final version is ready but who knows what other obstacles may spring up.

D/l RC2 and let us know how it goes on your system.

[Natsukashi53]

regarding the rc's I think it has something to do with raw files only. if I edit a jpeg, gif, tiff, etc, the edits are fine. I think it's the Raws that are the issue. I don't think the D4 is a problem. I think your D700 with have the same issue with its files. I was shooting with a 1DmkIII, still had the issues. and that's a considerably older camera with a smaller sensor than your D4 if I remember correctly.

I am almost positive that it is just a problem with raw files. maybe something to do with the size of the raw file etc.

Sent from my iPhone

[MarceloTrad]

Compression of the raw files maybe?

Marcelo Trad

[MarceloTrad]

had anyone noticed in RC2 the new module under Lens Correction? There is a

special feature just for Cromatic Aberrations

Marcelo Trad

[gregkmeyer]

Labs.adobe.com

This is a private communication sent from my mobile device. If you are not

the intended recipient, please delete this message from both your email and

your memory banks.

[gregkmeyer]

Or maybe they know exactly what is causing the problem. In software

development, sometimes the difficulty is not in finding what exactly is

triggering a problem, but how to solve it. in a case like that, additional

bug reports are unnecessary.

This is a private communication sent from my mobile device. If you are not

the intended recipient, please delete this message from both your email and

your memory banks.

[quenton8]

The fact that it "seems" to be worse on higher end machines may actually be reasonable.

Scheduling algorithms and often multi-process applications are written to fit certain response times.

Our office has run into such a case.  We run a high performance object database.  It runs really well

on SSD's -- "except" that if you run some task that runs for a long time and does lots of disk accesses

it kills most other sessions -- because, we think, it hardly ever gives up the CPU to wait for disk accesses.