Experiencing performance related issues in Lightroom 3.x

[laurencec]

Hi

I just upgraded from lightroom 2.7 to lightroom 3. I then proceeded to import my old catalog. this all went fine but lightroom is so slow, the thumbnail previews take forever to load if I manage to have the patience to wait  for them.

is there a quick solution?? How can it be sped up?

thanks

Laurence

Message title was edited by: Brett N

[camerahans]

Holy cow, LR is sure busy creating files and closing them and running queries while nothing being done with LR

[Guest]

GaryRowe wrote:

If you are on Windows and want to know what's happening on your system *in detail*, then I recommend the SysInternals Suite from Mark Russinovitch - download at

http://technet.microsoft.com/en-us/sysinternals/bb842062.aspx

My favourites are:

Process Explorer gives a great view of what process is doing what (and you can monitor LOTS on a per-process basis)

Process Monitor gives you every single thing happening on your system - it's scary! Learn how to exclude * filter stuff to be able to see the details you are interested in ...

RamMap lets you see overall and process memory usage, and I could see LR3 could take up to almost 3GB of my system's 4GB when I was going through my images in Loupe view  (and in the Files tab I could see the .tmp file that was discussed a few posts ago, taking up all that memory)

I've used these tools to solve many a strange issue in Windows systems over the years (and the tools keep getting better and better!)

Have fun,

Gary

Gary, thanks. I too am overwhelmed by how much info it presents us with. I'm wondering if there is someone here or someone at Adobe who could supply us with some filter options to provide consistent reports of some sort that would help them out. Without some guidance I don't know what to look for, and right now when I'm in the middle of wedding season I'm fairly busy just trying to edit images and don't have the down time to learn the software.

Thanks!

[JayS_In_CT]

DanTull wrote:

Some posts' symptoms include unnecessary re-rendering. At least one such case has been confirmed fixed internally.

Another cause for this kind of re-rendering, at least in the case of the Library loupe view, is if you've built "standard" previews but your screen size and panel configuration creates an area that requires a larger preview. In the latter case, see if the problem goes away when you reduce your window size.

There are options in Catalog Settings (File Handling tab) for increasing the size of standard size previews if it turns out to be a screen size mismatch issue.

DT

Dan,

I've tried 1440, 1620, and 2048 on my issues with the Dell 24", no help.  LR 3 has a much smaller image size resolution in Fit mode even with LR occupying the full 24" screen.  To confirm though, making the full frame of LR smaller by about 15% or increasing the width of the panels so the view window is smaller, all correct the "frozen in unresolved" state when doing develop edits and clearly speeds up previews in Library.  Just seems something about 1920x1200 and above makes LR unhappy.

Jay S.

[hwnoord]

4 to 8 seconds is the acceptably good performance on my HP Vista

laptop. On my XP desktop it goes to 85 seconds. HWNoord

[Gavin Farrington]

Hi Dan.  I did some experimenting with the cr_sdk_NNNNNNNN.tmp file, and here's what I've found.

Win7x64, LR3-64bit,

i7 920, 6GB triple channel DDR3,

WD 2TB Black = Images

(1) 150GB WD 10k Raptor = OS

(2) 150GB WD 10k Raptor = Camera Raw Cache, 20GB

I have a large library, but for these tests I worked with only two DNG files, both originally from a Canon 5d mk II.  Both are the 2010 process version, both have NR applied, and both have lens correction enabled.

At the start, both DNGs had basic color correction, white balance, and contrast adjustments.

"DNG A" had numerous localized adjustments - brushes, healing stamps, and gradiated filers already applied.

"DNG B" had no localized adjustments, so I was starting from scratch.

Lightroom was reportedly using ~1GB of "private working set" memory.

The cr_sdk_*.tmp file was non-existent.

After a few moments of working on DNG B, the .tmp file appeared at an initial size of ~136MB.

After about 10 minutes of working, the .tmp file had increased to ~510MB.  At this point the interface was growing a little sluggish, but not unusable.  For example sliders were jerky, and the ruby brush mask would take a moment to toggle on/off.

At this point I switched over to DNG A to make some minor tweaks.  Simply switching images (no edits or adjustments made) caused the .tmp file to grow to ~1.3GB.  In the process of opening DNG A, the Windows spinning ring appeared for about 20s, and the title bar for lightroom reported the application "unresponsive" during that time.  I also noticed constant HDD thrashing.  I made a few minor adjustments to this file, and the brushes and interface were extremely slow to respond.  I use the mousewheel to grow/shrink the brush.  When LR is behaving itself, the size change is fluid and fast.  At this point in my experiment though, it was roughly 1 second per one step increase or decrease in brush size.  Sliders were almost impossible to use, as each change required many seconds of waiting just to see the tick mark move on the bar.

Just for kicks, I then switched back to DNG B.  Again the .tmp file ballooned - this time to 2.6GB.  The application is so slow as to be unusable at this point.  Task Manager reports Lightroom at 2.1GB of "private working set" memory.

The .tmp file size appears to be persistent as long as LR is open.  Leaving the develop module does not shrink or remove the file.

Prior to exiting LR and restarting the app, my cpu/ram usage widget tells me 5,103MB of RAM is used out of 6,134MB.  I exited LR and almost immediately my total used system RAM drops to 1,940MB - a change of 3,163MB.  I didn't push as hard with this test, but on previous occasions I've seen LR take even more RAM - to such an extent that the OS itself starts swapping out necessary data.  For example just opening the Start menu can take tens of seconds while the HDD thrashes away.

Let me know if there's any more info I can provide.

[TK2142]

DanTull wrote:

Can others confirm that their slowdowns also correlate with the size of this file?

I can report that deteriation of adjustment brush performance (not quick but usable in the beginning to unbearable lag once a number of adjustements have been made) is unrelated to the existence of this file.

I'm using Windows XP, SP3 andI checked in the %TEMP% directory (and to make sure in the Adobe folder in the user settings directory). The file wasn't even there but cursors and adjustments are still unacceptably slow once I have applied a number of local edit operations.

[john Nall]

Ok.  I'm having similar problems as reported in this forum string. I'm using a 24" iMac, with operating system 10.5.8, 2.4 GHz Intel Core Duo processor, 4 GB 667 MHz DDR2 SDRAM.  Here's some other info:

Lightroom version: 3.0 [677000]

Version: 10.5 [8]

Application architecture: x64

Physical processor count: 2

Processor speed: 2.4 GHz

Built-in memory: 4096.0 MB

Real memory available to Lightroom: 4096.0 MB

Real memory used by Lightroom: 1050.6 MB (25.6%)

Virtual memory used by Lightroom: 3655.4 MB

Memory cache size: 225.3 MB

Displays: 1) 1920x1200

I captured my experience trying to use the adjustment brush in a video. I used a wider brush, then a smaller one.  No other program was running (other than  iShowHD).  You can see the video at http://jfnall.smugmug.com/Other/Movies/13203613_aKC5o#958477003_reRT2   As others have mentioned, at some point this program function (adjustment brush) becomes useless.

[Ian Lyons]

john Nall wrote:

I captured my experience trying to use the adjustment brush in a video. I used a wider brush, then a smaller one.  No other program was running (other than  iShowHD).  You can see the video at http://jfnall.smugmug.com/Other/Movies/13203613_aKC5o#958477003_reRT2   As others have mentioned, at some point this program function (adjustment brush) becomes useless.

It looks like you have the adjustment brush auto mask activated. How much, if any improvement, if any, do you see when you turn it off?

[john Nall]

Ian,

I didn't have the auto mask function checked. Right now, other functions are slow, too.  For example, applying some LR presets can take as long as 10-13 seconds.  Removing them can also take that long, if not longer.

I failed to mention that I'm using a Wacom tablet and images are from a Canon 7D, so about 18 or so megapixels.

[Ian Lyons]

john Nall wrote:

I failed to mention that I'm using a Wacom tablet and images are from a Canon 7D, so about 18 or so megapixels.

...and if you use a mouse instead of the Wacom?

...and reduce your window size so that it doesn't fill the full screen?

[john Nall]

Ian, reducing the screen size doesn't result in faster results.  Neither does using a mouse.  And, it takes more than 10 seconds to reset the brush (i.e. undoing the brush).

[JayS_In_CT]

john Nall wrote:

Ian, reducing the screen size doesn't result in faster results.  Neither does using a mouse.  And, it takes more than 10 seconds to reset the brush (i.e. undoing the brush).

John,

Take a quick search around this discussion group on Wacom.  Different users are having different experiences with Wacom (latest drivers, connected/not connected).  With your display at 1920x1200, there are some other rendering issues check this thread

http://forums.adobe.com/message/2891799#2891799

It has references to what Ian was suggesting as far as resizing the screen as well.

Are you starting with a fresh catalog or imported?

Jay S.

[john Nall]

Jay,

I'm embarrassed to admit I'm not clear on LR's catalog arrangement. All I know is I have one catalog that I store in an external drive.  My software is in the iMac's internal drive, and another drive is used solely for backups.

My one catalog has a number of photos (12,000 or so).  If any of this (1 catalog, placing pics in an external drive, etc) might be the issue, I'd be glad to initiate whatever changes needed.

I'll also finish reading the postings on this forum and check the link you provided.  Thanks, Jay.

[Gavin Farrington]

Jay, this isn't related to any bugs you may be experiencing, but a flag went up when you mentioned having your catalog on an external drive.  USB 2, Firewire, and Firewire 800 will all severely hamper the performance of your drive.  I highly recommend moving your catalog to an internal drive.

The only external interfaces that would provide enough performance are eSATA or USB3, but I'm betting that's not what you're using?

Good luck with your other issues. 

[JayS_In_CT]

Digihotaru wrote:

Jay, this isn't related to any bugs you may be experiencing, but a flag went up when you mentioned having your catalog on an external drive.  USB 2, Firewire, and Firewire 800 will all severely hamper the performance of your drive.  I highly recommend moving your catalog to an internal drive.

The only external interfaces that would provide enough performance are eSATA or USB3, but I'm betting that's not what you're using?

Good luck with your other issues. 

My catalog is on my internal macbook pro drive.  Sorry if I posted something else.  I thought I said I created another smaller catalog, but don't remember saying it was external drive.  That said, I have run with catalogs on external devices, with fairly large image counts and not really seen a major impact, at least up through 2.7 (on eSATA and FW800), but normally it is resident on the boot drive.  Thanks for looking out for me!  🙂

Jay S.

[john Nall]

I think you meant "John" but I understand since I've been names wrong all day.  Both my external drives are eSata, USB 2. I'm not using the 400/800 firewire.  I don't know whether the drives are chatting with my iMac using USB 2 or eSata. I don't know what those designations mean. 

But I might want to move a picture or two to the internal hard drive and see if LR3 behaves better.

Thanks for your comments.

[JayS_In_CT]

john Nall wrote:

I think you meant "John" but I understand since I've been names wrong all day.  Both my external drives are eSata, USB 2. I'm not using the 400/800 firewire.  I don't know whether the drives are chatting with my iMac using USB 2 or eSata. I don't know what those designations mean. 

But I might want to move a picture or two to the internal hard drive and see if LR3 behaves better.

Thanks for your comments.

John,

See..  We're all "clear headed" some of the time! 

Jay S.

[n781lc]

Off this topic so please forgive, just trying to help in an area that is a problem for some: organization.  Could even have misunderstood ...

"My one catalog has a number of photos (12,000 or so).  If any of this (1 catalog, placing pics in an external drive, etc) might be the issue, I'd be glad to initiate whatever changes needed."

John, about Library and catalogue organiztion. I hope I'm not intruding but no one seemed to jump at your 12,000 image in one catalogue which may be fine if in right place and you can get to each one..

To avoid assuming erroneously your actual system I will simply give mine and it's the same as Kelby and others seem to recommend.

On the Mac:  ALL original photos go direct to the HD in ONE folder. In my case: iMac HD>Photos> with sub-folders by years 1950-1980: 1981-2000; 2001-2010.  In each of these sub-folders is my selection of particular dates that contained a large number of files until the last 2010 and there I have by each year.  This when collapsed gives a very compact but easily spread view of all the ORIGINALS which are also backed up to the 1 TB HD on my desktop and to Mozy in the cloud.  I rarely even look at these; Collections serve the "breakdown into topics, subject, situations, etc." With proper tagging any file can be found.  Of course anything edited in Photoshop or Elements will be destructive but otherwise in LR everything in collections can be juggled, edited, or whatever without disturbing the original or basic structure.

Again, if this is old hat and I misunderstood, I do sincerely apologize to you and the group. 

Ed

[john Nall]

Thanks Ed.  I have a photos file contains all my pictures organized in several folders, similar to yours (I don't use years but "family, friends, vacations" etc.  Within each of those are numerous subfolders. My folders and sub-folders in Lightroom correspond to what's in the photos file on the hard drive.  The only collections I've created are those that started out as a quick collection, and typically represent a selection of pictures I plan to post.

Thanks again for the info.

[Ian Lyons]

john Nall wrote:

Ian, reducing the screen size doesn't result in faster results.  Neither does using a mouse.  And, it takes more than 10 seconds to reset the brush (i.e. undoing the brush).

The three checks that I suggested are known workarounds for the issue you're video displays. Given that neither of them helps it would seem that your  specific issue is very likely due to one of those that hasn't yet have a workaround* or at least one that I'm aware of.

* I'm not suggesting that folk should be using workarounds, just that they give a good indication of cause.

[Ian Lyons]

john Nall wrote:

Ian, reducing the screen size doesn't result in faster results.  Neither does using a mouse.  And, it takes more than 10 seconds to reset the brush (i.e. undoing the brush).

Another suggestion, - do exactly as described below:

1. Select the Brush tool (do not use it)

2. Hit E key (switches to Library module)

3. Hit D key (switches back to develop module, but the brush will have been deactivated)

4. Reselect the Brush and apply as required

I'll be very surprised if it helps in this particular instance, but confirmation would be useful to have.

[JayS_In_CT]

Ian Lyons wrote:

john Nall wrote:

Ian, reducing the screen size doesn't result in faster results.  Neither does using a mouse.  And, it takes more than 10 seconds to reset the brush (i.e. undoing the brush).

Another suggestion, - do exactly as described below:

1. Select the Brush tool (do not use it)

2. Hit E key (switches to Library module)

3. Hit D key (switches back to develop module, but the brush will have been deactivated)

4. Reselect the Brush and apply as required

I'll be very surprised if it helps in this particular instance, but confirmation would be useful to have.

Ian,

How did you even FIND that one? 

Jay S.

[john Nall]

Ian, believe it or not, your suggestion to open the brush, switch to Library and then back to Develop, reopen the brush...worked!  At least it worked Wednesday, August 4, at 3:02 Pacific Time. 

Unfortunately, it took LONGER to reset the brush---over 15 seconds. 

[Ian Lyons]

john Nall wrote:

Unfortunately, it took LONGER to reset the brush---over 15 seconds. 

You'll need to explain what you mean by above. What you did? What Lr did? etc

[john Nall]

Jay, if you're referencing "resetting" the brush, I meant that I applied the brush, with the selected mask overlay checked so I can see what's covered, and then hit the "reset" item in the Brush box, to clear the brush's effect on the picture.  When I did that, it took 15 seconds to clear the picture of brush corrections.