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
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
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.
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.
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
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.
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.
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..
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.
Copy link to clipboard
Copied
On 8/4/2010 11:19 AM, JayS In CT had this to say:
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
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.
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
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.
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.
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
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?
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
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.
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.
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.
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!
Copy link to clipboard
Copied
Thanks for the update! Very encouraging news.
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?
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
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
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.