• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
Locked
0

Experiencing performance related issues in Lightroom 3.x

New Here ,
Jun 09, 2010 Jun 09, 2010

Copy link to clipboard

Copied

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

Views

283.2K

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 1 Correct answer

Adobe Employee , Dec 02, 2010 Dec 02, 2010

FYI, I need to lock this thread and start a new thread because I fear that customers will attempt to share valuable feedback in this discussion and it has become extremely difficult for the Lightroom team to follow the lengthy and increasingly chatty conversation.  Please use the following forum topic to discuss the specifics of your feedback on Lightroom 3.3.

http://forums.adobe.com/thread/760245?tstart=0

Regards,

Tom Hogarty

Lightroom Product Manager

Votes

Translate

Translate
replies 1198 Replies 1198
Explorer ,
Aug 02, 2010 Aug 02, 2010

Copy link to clipboard

Copied

Keith_Reeder wrote:

goodlux7 wrote:

You should start a post "OMG. I can you believe how SMOKING FAST lightroom 1s!?!?" Then we'll have an apples to apple comparison.

Oh give a rest, will you? We get it - you're not happy. Get over it.

I have zero interest in persuading you or anyone else that Lr is fine on my machine, and could not care less if you have a problem accepting it.

Keith / Goodlux7,

Can we try to keep some civility here..

Goodlux, in Sherlocc's post, he does propose a "faster then 2.x" category, so what you're suggesting would be captured I think.

Keith.. As I said in a previous post, knowing what makes LR fly on some machines is almost as important as knowing what causes it to crawl on another.  If you want to help Adobe and others, great, otherwise I don't understand your post.

Jay S.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Aug 02, 2010 Aug 02, 2010

Copy link to clipboard

Copied

JayS In CT wrote:

otherwise I don't understand your post.

It's very simple, Jay - I deeply resent the implication from his previous post that I'm some sort of Adobe fanboy who, simply because I've expressed satisfaction with Lr 3, must be put on the spot and challenged.

If he'd wanted to engage in a meaningful conversation with me, he might have said something along the lines of "Keith, can you tell me how long it takes you to do action X with Y number of files?" or "do you see any delays building up when you've been working for a while?" or... whatever.

But no, that was beyond him. He just couldn't resist characterising my reported enthusiasm for Lr 3 as the inane text-speak waffling of some pre-pubescent schoolgirl, and I'm not having that. It seems to me that he just doesn't like the fact that for all his complaining about Lr 3, his experience of it isn't the only one, and he resents the fact that not everyone else is as miserable as he is.

Let's be in no doubt that his moaning hasn't moved anything on constructively either.

I've already provided my computer's spec on this thread, and I reiterate that I have experienced none of the most-reported problems posted here - I experience no delays in any of the areas where others have had issues, and the program just ticks along quickly, quietly, effectively and without fuss, no matter what I do with it.

But I've already said all this. And trying to come up with ad hoc benchmarks that have any relevance or meaning without first robustly defining the parameters of the exercise (up to and including organising a standard set of RAW files - and plenty of 'em - with which to conduct the tests), is pointless.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Guest
Aug 02, 2010 Aug 02, 2010

Copy link to clipboard

Copied

Keith_Reeder wrote:

sherlocc wrote:

This thread has had 36,230 posts by 726 people.

Uuummm... no.

36k+ views, 700+ posts, many by the same few folk.

Just saying...

But these figures further serve to make your point - the complaints on here cannot be taken with any certainty as being representative of the overall user experience out there: and bear in mind too that some of us have posted in this thread to say that all is well in Lightroom Land for us - and I'm not really what you'd call a "Bleeding Edge" user either.

  Thanks!

  Sorry about that, my bad!

  That would be 36,230 views, and 732 replies by ??? people!

  When you get to be my age, you will understand the problem.

  Best Regards,

  Sherlocc

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Aug 02, 2010 Aug 02, 2010

Copy link to clipboard

Copied

Keith_Reeder wrote:

sherlocc wrote:

This thread has had 36,230 posts by 726 people.

Uuummm... no.

36k+ views, 700+ posts, many by the same few folk.

Just saying...

But these figures further serve to make your point - the complaints on here cannot be taken with any certainty as being representative of the overall user experience out there: and bear in mind too that some of us have posted in this thread to say that all is well in Lightroom Land for us - and I'm not really what you'd call a "Bleeding Edge" user either.

I rather liked being a bleeding edge user for a moment, anyway. 

Just to note, I did submit a formal bug report.

My main issues were:

1) Lagging sliders

2) slow to render before being able to edit

3) failed exports.  When exporting to jpeg, I often have about a 5% failure rate.  The app gives the option of showing them in the library, and from there I re-export them and usually they export fine.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Aug 02, 2010 Aug 02, 2010

Copy link to clipboard

Copied

36k+ views, 700+ posts, many by the same few folk.


The number of views isn't a particularly good metric since the forum software doesn't differentiate between new viewers and folk returning to see what's new. For example, as the Forum Host I may view this thread a dozen or more times per day. I open the thread to see what's new, which there hasn't been for weeks.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Aug 03, 2010 Aug 03, 2010

Copy link to clipboard

Copied

My desktop suffers this slowing issue (and then blanking of thumbs, etc) but not the laptop.  Desktop is Win7x64,12gb, i7.

Just reporting a symptom which I just noticed that may be shared by others, that hopefully may be of value to anyone at adbe doing research into the issue.

When the slowdown becomes apparent (just flipping through in loupe view and doing selects will cause this on my machine), a tmp file appears in the %temp% directory.  (Not the raw cache directory, which i have allocated somewhere else at 30gb).

This tmp file is of the filename cr_sdk_NNNNNNNN.tmp

This tmp file either stays "contained" in size, which means a bearable slowdown.  Or will suddenly ballon to like 15-20gig in size, at which point LR3 is pretty much unusable (such as not even drawing the loupe view image, blank thumbnails, etc).  This has nothing to do with the adobe raw cache location, which even if cleared, does not fill to max allocated when the above tmp file starts appearing.  The tmp file is deleted by LR upon exit of course.

I can see a need for working tmp files.  But a 15 gig tmp file seems a little much for generic raws from 5d, 5dm2, 1dm4, d700 or d3 cameras.


wonder if anyone else with the slowness sees this large file appear as well..

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Aug 04, 2010 Aug 04, 2010

Copy link to clipboard

Copied

trevpl wrote:

..........

This tmp file is of the filename cr_sdk_NNNNNNNN.tmp

...........


wonder if anyone else with the slowness sees this large file appear as well..

Trevpl,

Hmm..  I'm on a Mac, so not sure if there is a similarly named file, but will look.  Also, if you haven't already, you should get it into the Adobe system via this link.

http://www.adobe.com/cfusion/mmform/index.cfm?name=wishform

No guarantees it will get picked up here..

Jay S.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Aug 04, 2010 Aug 04, 2010

Copy link to clipboard

Copied

On 8/4/2010 11:19 AM, JayS In CT had this to say:

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Aug 04, 2010 Aug 04, 2010

Copy link to clipboard

Copied

This tmp file is of the filename cr_sdk_NNNNNNNN.tmp ... Or will suddenly ballon to like 15-20gig in size, at which point LR3 is pretty much unusable ...

Interesting observation...that file is essentially an LR (or rather ACR) specific swap file, so a ballooning effect like that corresponding to a severe slowdown makes perfect sense. It's essentially like a memory usage spike that task manager can't show you.

That's definitely a useful bit of info. Can others confirm that their slowdowns also correlate with the size of this file?

DT

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Aug 04, 2010 Aug 04, 2010

Copy link to clipboard

Copied

DanTull wrote:

This tmp file is of the filename cr_sdk_NNNNNNNN.tmp ... Or will suddenly ballon to like 15-20gig in size, at which point LR3 is pretty much unusable ...

Interesting observation...that file is essentially an LR (or rather ACR) specific swap file, so a ballooning effect like that corresponding to a severe slowdown makes perfect sense. It's essentially like a memory usage spike that task manager can't show you.

That's definitely a useful bit of info. Can others confirm that their slowdowns also correlate with the size of this file?

DT

Dan,

Is there something similar on the Mac?  I searched for anything close in naming and got nothing.

Jay S.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Aug 04, 2010 Aug 04, 2010

Copy link to clipboard

Copied

This tmp file is of the filename cr_sdk_NNNNNNNN.tmp ... Or will suddenly ballon to like 15-20gig in size, at which point LR3 is pretty much unusable ...

Is there something similar on the Mac?  I searched for anything close in naming and got nothing.

Yes, but in my case I had to push pretty hard to get it to appear at all.  Here's an example of how I looked for it, where 1393 is LR's PID.

$lsof -p 1393 | grep tmp

... /private/var/folders/f2/f2EpNrhRHUW03uBeAA9DN++++TI/Cleanup At Startup/cr_sdk_94967295.tmp

DT

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Aug 04, 2010 Aug 04, 2010

Copy link to clipboard

Copied

DanTull wrote:

This tmp file is of the filename cr_sdk_NNNNNNNN.tmp ... Or will suddenly ballon to like 15-20gig in size, at which point LR3 is pretty much unusable ...

Is there something similar on the Mac?  I searched for anything close in naming and got nothing.

Yes, but in my case I had to push pretty hard to get it to appear at all.  Here's an example of how I looked for it, where 1393 is LR's PID.

$lsof -p 1393 | grep tmp

... /private/var/folders/f2/f2EpNrhRHUW03uBeAA9DN++++TI/Cleanup At Startup/cr_sdk_94967295.tmp

DT

Dan,


Thanks..  I'll look tonight and see if it is happening here.

Jay S.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Aug 04, 2010 Aug 04, 2010

Copy link to clipboard

Copied

JayS In CT wrote:

DanTull wrote:

This tmp file is of the filename cr_sdk_NNNNNNNN.tmp ... Or will suddenly ballon to like 15-20gig in size, at which point LR3 is pretty much unusable ...

Is there something similar on the Mac?  I searched for anything close in naming and got nothing.

Yes, but in my case I had to push pretty hard to get it to appear at all.  Here's an example of how I looked for it, where 1393 is LR's PID.

$lsof -p 1393 | grep tmp

... /private/var/folders/f2/f2EpNrhRHUW03uBeAA9DN++++TI/Cleanup At Startup/cr_sdk_94967295.tmp

DT

Dan,


Thanks..  I'll look tonight and see if it is happening here.

Jay S.

Dan,

I entered the string "$lsof -p 1393 | grep tmp"  (no $) and replaced 1393 with the PID on my system and just got a blank line back.

Jay S.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Aug 05, 2010 Aug 05, 2010

Copy link to clipboard

Copied

Yeah, for me I had to keep pushing on LR to even get to create the file. It doesn't create it until it needs to page some tiles out of memory to make room.

DT

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Guest
Aug 05, 2010 Aug 05, 2010

Copy link to clipboard

Copied

I am also experiencing very bad 'slowness' with LR3.  In particular which simply switching form image to image in any mode, it takes several seconds for the image to 'render'... up to 5 seconds.  Even when they've been 'rendered' previously.  Is this the same issue(s) that everyone else is having in this thread?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Aug 05, 2010 Aug 05, 2010

Copy link to clipboard

Copied

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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Aug 05, 2010 Aug 05, 2010

Copy link to clipboard

Copied

I think I have figured out when the slowness problem happens for me. Previously, it seemed random, but I've now narrowed it down to certain actions that I take.

My workflow usually includes importing (usually jpgs at this time), keywording those imported photos (I have a long list of keywords), then exporting to various folders. Then, I either search for the photos using a Smart Collection, or I create or edit a Smart Collection to fit what I'm looking for. I also have an extensive Smart Collection.

It is *after* I work with the Smart Collections and go back to keywording that LR slows to a crawl. This is the point where keywording slows to be almost unuseable, and any subsequent exports take anywhere from 15 minutes to an hour. So as far as I can tell on my machine, it's working with Smart Collections that is bringing everything down.

I have tried optimizing the catalog immediately after I work with any collections, and that has seemed to help (have only done it a couple times so far) as a workaround in the meantime. I feel like I have to be really careful about what order I do anything in so that I don't make LR wig out.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Aug 05, 2010 Aug 05, 2010

Copy link to clipboard

Copied

You have impeccable timing. A bug fix related to certain kinds of keyword text matching smart collections causing severe CPU usage and delays in processing of data requests (basically, anything in the UI that needs  to wait for data from the catalog) just got confirmed fixed internally.

DT

P.S. Yes, we're going to get a build with the various fixes to which I've alluded to folks at some point in the (not so distant, but nonetheless indeterminate) future. Honest. It kills me that I'm not supposed to say more than that.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Aug 05, 2010 Aug 05, 2010

Copy link to clipboard

Copied

DanTull wrote:

You have impeccable timing. A bug fix related to certain kinds of keyword text matching smart collections causing severe CPU usage and delays in processing of data requests (basically, anything in the UI that needs  to wait for data from the catalog) just got confirmed fixed internally.

DT

P.S. Yes, we're going to get a build with the various fixes to which I've alluded to folks at some point in the (not so distant, but nonetheless indeterminate) future. Honest. It kills me that I'm not supposed to say more than that.

Dan,

Sounds like a much broader reaching fix than just keyword impact.  Can't wait to get some of those CPU cycles back.  🙂

Jay S.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Guest
Aug 05, 2010 Aug 05, 2010

Copy link to clipboard

Copied

Dan,

Sounds like a much broader reaching fix than just keyword impact.  Can't wait to get some of those CPU cycles back.  🙂

Jay S.

WooHoo - same here!

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Aug 05, 2010 Aug 05, 2010

Copy link to clipboard

Copied

Thanks for the update! Very encouraging news.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Aug 05, 2010 Aug 05, 2010

Copy link to clipboard

Copied

Dan,

I see in lightroom that you can set the "standard" previews to various sizes. Does the pixel count (1440,1680, etc) refer to the width of the image preview itelf? And since everybody screen resolution and size is different, how can we efficiently calculate the appropriate size to set for our previews? Should we set up our window, and do a screen shot and crop out the preview and look at the pixel width of it?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Aug 06, 2010 Aug 06, 2010

Copy link to clipboard

Copied

Thanks Dan, for your words of encouragement!  I'm sure we are all looking forward to the first dot release. I just ran into the keyword/smart collections slow down, big time.  Sigh.

By the way, should I put in a bug about the memory leaks I've documented in another thread?  Is that one that is being worked on?

Thanks!

Jason

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Aug 06, 2010 Aug 06, 2010

Copy link to clipboard

Copied

We just confirmed a fix for a mistake in the way cached previews were being accounted for internally. Previews are used pretty extensively throughout the app, but the most glaring place that one would show up was during sustained rapid advances through Library loupe on a large monitor.

It took a bit to confirm the right fix for it because the caching is done intentionally and on other setups the build up would tend to recover quickly enough that it just seemed like the garbage collector was getting (relatively harmlessly) a little bit behind.

I think there's may still some memory buildup issues in Develop to root out, especially around the caches used to improve interactive performance while brushing and spotting, but there's more analysis to be done there and as with any caching we have to be careful not to slow things down by caching too little.

DT

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Aug 06, 2010 Aug 06, 2010

Copy link to clipboard

Copied

DanTull wrote:

We just confirmed a fix for a mistake in the way cached previews were being accounted for internally. Previews are used pretty extensively throughout the app, but the most glaring place that one would show up was during sustained rapid advances through Library loupe on a large monitor.

It took a bit to confirm the right fix for it because the caching is done intentionally and on other setups the build up would tend to recover quickly enough that it just seemed like the garbage collector was getting (relatively harmlessly) a little bit behind.

I think there's may still some memory buildup issues in Develop to root out, especially around the caches used to improve interactive performance while brushing and spotting, but there's more analysis to be done there and as with any caching we have to be careful not to slow things down by caching too little.

DT

Dan,

Great news.  I was never able to create a situation on the Mac where that tmp file was created.  I don't know if other Mac users have seen it or not.  Perhaps more common on Windows machines, although I would have thought a similar system would be used on the Mac as well (some form of temp file).

Jay S.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines