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

[JayS_In_CT]

Digihotaru wrote:

FWIW I find LR's responsiveness improves dramatically for my workflow by pre-rendering 1:1 previews for the set of images I'm about to work on, so for people who work this way bothering with the other previews isn't much use anyway.  Personally I turn all preview rendering off during import because there's always a few blocks of images for which I want to tweak the white balance.  After getting through that step I select everything, render 1:1's, get coffee, then come back to work on a snappy system.

Yep, agree with that as well...  It seems the intial load helps over all.

Jay S.

[goodlux7]

Thank you for the pointer to this info. This is VERY helpful for

understanding what is going on in the background.

A couple things to note here:

1. Screen size is NOT the same thing as optimal preview size. For instance,

if you are using a 27 iMac, your resolution is: 2560-x-1440. So what size

preview is "the best?". You would think that since the long edge of the

screen resolution is 2560, that a preview with 2560 resolution (if there

were such a thing) would be the best. This might lead a user to think that

they only have the option of using 1:1 previews to get the optimal

experience on a 27 iMac. This isn't the case though.

The limiting side in this case is 1440, your image will never be "taller"

than 1440, no matter if it a portrait or a landscape. My camera (7d) has a

2:3 resolution...so the widest image from my 7d that I can possibly see on

the screen is 2160.

1440 / 2 * 3 = 2160.

When you take into account that the Lightroom application takes up some of

the pixels on the top and bottom of the screen, you can then see that the

2048 standard preview size is sufficient. You shouldn't have to do 1:1

previews for LR to be optimal.

2. But there is more to the story here. It might be that 2048 preview size

is less than optimal, because it is actually too big. It takes some time to

load the preview from the disk, and if you are working with a big preview,

it's going to take longer to grab from the disk. Modern computers are pretty

good at up-sampling images.

On the other hand, it is going to a little time for the processor to resize

the images, because the LR interface isn't "fixed" in size, and the user can

change things around. So it is really random what size the preview is

actually going to be in the end.

I did some tests looking at various size/compression previews, and I

couldn't visually tell a difference (on the 27in iMac) between 2048 and

1680. It seemed to me that the 2048 was SLOWER rendering though, which is

contrary to what you would think, since that would be the "right" size for

the monitor.

So in the end I just wasn't sure which was best, because I couldn't tell

which previews (on the disk) I was actually looking at.

One solution to some of these problems would be to have a SQUARE shaped

reviewing interface that is fixed according to the monitor size. This would

only be for the Filmstrip view (or some new mode), not the develop where you

absolutely need to see the whole screen, and you are rendering 1:1 anyway.

So the "portal" that images show up in would have the same length and width,

and this would be the exact size of the standard size preview. So the image

would not have to be resized after it is grabbed from the disk. This has the

added perceptual benefit of not being "jumpy" as the user moves though

images with different aspect ratios.

Finally, ideally the compression ratio would be automatically sensibly set

based on user testing, so there isn't a situation where the previews are

"heavier" than they should be. This would make things super-fast.

r

ps the preview pyramid concept is pretty cool. It would be neat to see that

info in the UI somehow.

[Gavin Farrington]

Goodlux7's reasoning sounds good on the preview size considerations.  It still comes down to your individual workflow, though.  I use 1:1 loupe mode a lot to compare sharpness between iterations of similar images.  If you zoom in to 1:1 often, pre-rendering the 1:1 previews will really speed things up.

[areohbee]

Thanks Ian,

But I still have these questions:

1. Are the previews in this pyramid for Libary only, or Develop too?

2. Are all the smaller previews rendered too whenever you request rendering of a particular size, or Lightroom deems it necessary to render a particular size?

3. Are all previews in the pyramid invalidated as soon as you make the first develop settings adjustment? If not which ones are, and which ones are not.

4. Once invalidated, are they rebuilt in the background for selected photo(s), or only upon demand.

My apology if these questions were already answered and I just didn't read carefully enough.

Rob

[Gavin Farrington]

As I understand it, the previews in the Library module have nothing to do with what you see in develop.  Develop provides a super high quality image based directly on the RAW (or source) data.  The library module uses preview data for performance reasons.  Thus, no matter what level previews you render, you shouldn't expect to see any changes in performance to the develop module.

[DdeGannes]

This has always been my understanding of the role of the individual modules.

[areohbee]

Ah yes, its coming back to me now:

The ACR cache is for 1:1 Develop views (not previews) - there may be some caveat regarding standard view sizes in Develop module depending on process version.

[JayS_In_CT]

Ian Lyons wrote:

JayS In CT wrote:

So based on what you're saying should I pick a larger preview size?  1024 is the smallest and was thinking it would help.  I was using 1440.  I've got a 24" Dell Ultrasharp (love it)...  I'd love to get these load times down in Library mode..  I was figuring smaller previews shorter loads..

Your standard-sized preview setting should be as close as you can get to your actual monitor resolution. For those using a display with long side equal or greater than 1920 pixels that means you need to go with 2048 pixels. You choose as setting less than this and Lr will build the larger preview as soon as you view the image in the Library/Develop module content area.

BTw: the cache you mention earlier is for the Develop module only. It has zero benefit in Library module.

Ian,

Thank you for explaining that.  I had it wrong in my mind as well I guess..  So, what's the best way to go back and re-render standard size to a larger default (given my 1920 screen)?  Do I have to wipe out the previews folder again, or can I just up the res. and select all and redo the render standard size preview.  Guess I could try it, huh?   I hate to mess with that folder again, Develop is running very well now..   Thanks again..

Jay S.

[hwnoord]

   Just reporting that I have the memory drain issue on my desktop using
Windows XP, which successfully ran versions 1 and 2 with various upgrades.  Everything now impossibly slow.  On my laptop using Vista (a several year old computer) version 3 works acceptably well.  Neither are super fast processors, and both have 2 GB memory.   The problem is I use the desktokp for real Lightroom work as the monitor is bigger and better.  Many have described a similar problem.  I hope an updrade can be found which will solve this problem.  hwnoord

[Guest]

Reporting in also. Seems like a lot of Mac people on here, so as a PC user I wanted to post my system info up:

Lightroom version: 3.0 [677000]
Operating system: Microsoft Windows XP Professional Service Pack 3 (Build 2600)
Version: 5.1 [2600]
Application architecture: x86
System architecture: x86
Physical processor count: 4
Processor speed: 2.3 GHz
Built-in memory: 3326.1 MB
Real memory available to Lightroom: 716.8 MB
Real memory used by Lightroom: 618.3 MB (86.2%)
Virtual memory used by Lightroom: 593.4 MB
Memory cache size: 0.0 MB
System DPI setting: 96 DPI
Displays: 1) 1920x1200
Serial Number: removed by forum host

Application folder: C:\Program Files\Adobe\Adobe Photoshop Lightroom 3
Library Path: C:\Documents and Settings\LydellPhoto\My Documents\My Pictures\Lightroom\2010 Events\2010 Events-2.lrcat
Settings Folder: C:\Documents and Settings\LydellPhoto\Application Data\Adobe\Lightroom

Our files are RAW files shot with Canon 5D.

I cannot believe how incredibly slow this is compared to 2.7. We shoot weddings, and therefore are dealing with several thousand images per shoot and the extra time it's taking is very painful. It's effectively doubled my production time at least. I'm also running it on two other laptops, but it's pretty much unuseable on them.

I know there has to be an update in the works. Is there any projected date for when we will get some relief? I've tried pretty much anything I could read about inthe forums to see if there is a way to speed things up, but so far nothing is working. About the only thing I can see that makes a difference is simply leaving the computer on for like a day with lightroom open so it can finish caching and building previews - which take an extremely long time to build compared to 2.7.

If we want to roll back to 2.7, is Adobe taking refund requests? This is one instance where I needed to have waited on the upgrade.

I have to finish the current projects in the workflow pipeline and then decide if I want to go back to 2.7.

Message was edited by: IanLyons

[frank0239]

You should edit out your serial number before posting.

[Guest]

oh - didn't even see that. Thanks for editing that out!

[TonyBrook]

Dear Adobe

After "wasting" several hours reading forums here and elsewhere on the unacceptably slow operation of Lightroom 3, I am compelled to add my voice to those of the others here who are demanding that Adobe acknowledge a serious performance issue with the product.

I use LR professionally on two different Vista 32 systems that both ran LR 2.7 extremely well.  The degradation in operational performance introduced by LR3 on both machines is so severe that the product is unuseable, as it causes a major delay in my workflow - sitting watching the "processing" logo spinning on the screen is giving me nightmares!  Hence, I am stripping out LR3 and reverting to 2.7.

I am IT literate and there is lots of potentially useful comment and advice here and elsewhere on what may be the cause of the problem.  However, software vendors are duty bound to ensure their product is fit-for-purpose - they cannot expect purchasers to research issues at length and try various technical options for achieving a level of performance improvement.  This is especially true when the vendor is allegedly selling a product for use by professionals.

The new functioanlity is LR3 is welcome, but the product should not have been released without effective testing and, where appropriate, real-world advice on the minimum system configuration, and, if appropriate, the correct method of migrating catalogues from one version to another.

Regards

Tony

[getho]

jay

I'm actually using it in a window 2100x1400, and smaller if I need to do quick adjustments - yes it does speed  up in a smaller window, (but not the preview rendering)

When it looks like this...

(a window 1300x800).  It is almost as fast as OLONEO is at fullscreen (2560x1440).  When that program is fullscreen the image size is 1931x1286 (2.5MP), the LR image window here is 555x371 (0.21MP). Making LR 12 times slower (or 12 times smaller for comparable speed)

I know oloneo is not comparable to LR in any other way -

but it shows what is technically possible.

I'm not sure the graphics driver would impact on performance - certainly not with rendering of preview - which is the same speed at any window size - thats a pure CPU/memory task I would think.

Just tried looking at my resource meter whilst rendering previews.  I see a sawtooth pattern with peaks in CPU corresponding with troughs in disk writes.  My catalogue for this project is on the same drive as the RAW files - not sure if that makes a difference.  There was little writing to the cache (which is on a separate drive).

[Mikkasa]

getho wrote:

There was little writing to the cache (which is on a separate drive).

One proven bottleneck issue involves external drive access. Have you tried setting up a catalogue with everything on your internal drive?

[getho]

no its separate, but not external (its a 10K RPM raptor), storage is a raid 10

[DJ-G]

getho,

So you have the catalog and images in your main storage area, which is a RAID 10 (implying at least 4 drives) and the cache is in a separate internal Raptor drive. Should be pretty much ideal other than having the cache in a RAID 0 volume ( my setup :-). I take it the RAID 10 is internal too?

It would be nicer if one could locate the previews in a different drive too.

[rlv52]

Lightroom 3 is horribly, horribly slow!  No question whatsoever, it is virtually unusable.  My system is a new iMac (2.66 GHz Intel Core i5) with 12 GB of RAM.

My files are imported and stored on a NAS (QNAP).  With LR 2.7 there was absolutely no problem and excellent speed importing.  As soon as I switched to LR3, importing slammed into slow, slow, slow.

Adobe has a major problem.  I'm not even wasting my time with LR3--back to LR 2.7 I go!

[DanTull]

Details? Import in place, copy, move, DNG, or copy/convert from card? What kind of photos and how many? What part is slow exactly? (walltime of the import itself, sluggishness using the app during import, preview building, loading thumbs into grid, etc) What other settings are involved? Are you applying keyword/metadata/develop presets? Renaming? Is the catalog on an internal or external drive? If you're copying/converting/moving are you segmenting by date? Copying to a secondary location (if so, what kind of drive)?

The number of permutations of import is incredibly large, so specificity is key here. There are some cases for which 3.0 is substantially faster on multi-core systems, but it's certainly possible there are other aspects that are slower (preview building, in particular).

[rlv52]

Details:

Copy from card reader to NAS (external on my home network with a gigabit swich)

RAW files

On this import about 40 images, but not unusual to import several hundred RAW images from a card.

The slowness is in the previews showing up, but that simply indicates that the transfer to the NAS is slow

I am renaming and segmenting by date, but this import is only a single date (tonight).  No presets, keywords, or metadata are being applied.

All I know is the LR 2.7 works and with exactly the same setup presets etc, LR3 is ridiculously stunningly, unusably slow.  The only new variable is LR3.

[JayS_In_CT]

rlv52 wrote:

Details:

Copy from card reader to NAS (external on my home network with a gigabit swich)

RAW files

On this import about 40 images, but not unusual to import several hundred RAW images from a card.

The slowness is in the previews showing up, but that simply indicates that the transfer to the NAS is slow

I am renaming and segmenting by date, but this import is only a single date (tonight).  No presets, keywords, or metadata are being applied.

All I know is the LR 2.7 works and with exactly the same setup presets etc, LR3 is ridiculously stunningly, unusably slow.  The only new variable is LR3.

rlv52,

There has to be something far different between our systems in the way LR 3 is operating.  Check out my post a page back ( http://forums.adobe.com/message/3005521#3005521 )  with a goal of comparing 2.7 and 3.0 32 bit and 64 (at least on the import side and some load times on both Library and Develop).  I've got a 3 year old Macbook Pro with 4GB RAM and a Core 2 Duo processor.  Is my 3.0 slower than 2.7..  in some areas, absolutely yes, are there some things that irk me no end, e.g. high res. external monitor issues, yes.. but it would be useful if you could start of with just some straight imports, some side by side comparisons, perhaps move the image file location, etc., to see if it makes any difference.  You're not the only one with newer more powerful Macs that seem to have issues.  If you narrow down anything it might help us all.

Jay S.

[rlv52]

I'll have to try a few things to tune it a bit; no doubt importing to my NAS is slower than importing right to my Mac's HD, but the differences between 2.7 and 3 are striking. My suggestion to this (disgrunteld, but very accurate) group is to pepper Adobe with complaints.  I for one am calling tech support tonight to see if they have any suggestions, but mainly to sound off about this unacceptable issue.

[JayS_In_CT]

rlv52 wrote:

I'll have to try a few things to tune it a bit; no doubt importing to my NAS is slower than importing right to my Mac's HD, but the differences between 2.7 and 3 are striking. My suggestion to this (disgrunteld, but very accurate) group is to pepper Adobe with complaints.  I for one am calling tech support tonight to see if they have any suggestions, but mainly to sound off about this unacceptable issue.

You can also document it at this link for Adobe to get it...

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

you can report it as a bug.

Jay S.

[Guest]

I went a reported it at the Adobe link, but since they want concrete steps to reproduce it I'm not sure I was much help. I'm not doing anything other than using the program the same exact way I was using 2.7, and the speed difference is excruciating. It has flashes of brilliance, but then bogs down again before I can get very far.

What tools can I use to measure my CPU to give results Adobe can use?

Has ANYONE heard back from Adobe with any kind of timeline on when there will be an update?

[rlv52]

I just sent them my original post and noted that the Adobe Forums were ablaze with indignation at this problem.  They know.