Lightroom 3.3 Performance Feedback

[Tom Hogarty]

Please use this discussion topic for your feedback on Lightroom 3.3 RC and the final Lightroom 3.3 release when it becomes available.  The Lightroom team has tried very hard to extract useful feedback from the following discussion topic but due to the length and amount of chatter we need to start a new, more focused thread.  Please post specifics about your experience and be sure to include information about your hardware configuration.

Regards,

Tom Hogarty

Lightroom Product Manager

[TK2142]

tgutgu wrote:

Version 3.3 is a release candidate submitted to the public for testing. It does not mean that it is ready for production, although close to it. If a broken TAT tool is a reason to hold back a release candidate is debatable, but I would not call the importance of it so high.

The fact that it is a candidate and the associated wording regarding "sufficiently tested" (or similar) strongly suggest that things are fine from Adobe's point of view. In other words, ideally the candidate  should turn into the real thing without further change.

Knowing about a broken TAT tool and still releasing an RC would mean that you are either only inviting input from Mac users or people with spare Windows machines (since you cannot run 3.2 and 3.3RC side by side on a single Windows machine) or that you take the stance that people don't use the TAT tool. Neither of these alternatives seem to be realistic propositions.

tgutgu wrote:

I thought that this thread is not for ranting, but purely for reporting and discussing solutions of performance issues including the exact specifics (as far as a user can tell it) under which the issue occurs and what the extent (timings) of the issue is.

I had to make the comment of not being able to run 3.3RC since I wanted to report an annoying problem but couldn't be sure whether it still persists in 3.3RC. Luckily Lee Jay (and maybe others) found my "rant" useful. Please forgive me for not opening a new thread for making the remark that I find it frustrating that I cannot provide feedback because Adobe's "one Windows installation only" and "release without extensive testing on several platforms" policies. BTW, it's not like that obvious bugs (easy to find on all platforms) have never been included in official releases. Whether its the QC team or publication targets, this is not the state of the art in software engineering.

[Guest]

TK2142 wrote:

tgutgu wrote:

Version 3.3 is a release candidate submitted to the public for testing. It does not mean that it is ready for production, although close to it. If a broken TAT tool is a reason to hold back a release candidate is debatable, but I would not call the importance of it so high.

The fact that it is a candidate and the associated wording regarding "sufficiently tested" (or similar) strongly suggest that things are fine from Adobe's point of view. In other words, ideally the candidate  should turn into the real thing without further change.

Knowing about a broken TAT tool and still releasing an RC would mean that you are either only inviting input from Mac users or people with spare Windows machines (since you cannot run 3.2 and 3.3RC side by side on a single Windows machine) or that you take the stance that people don't use the TAT tool. Neither of these alternatives seem to be realistic propositions.

tgutgu wrote:

I thought that this thread is not for ranting, but purely for reporting and discussing solutions of performance issues including the exact specifics (as far as a user can tell it) under which the issue occurs and what the extent (timings) of the issue is.

I had to make the comment of not being able to run 3.3RC since I wanted to report an annoying problem but couldn't be sure whether it still persists in 3.3RC. Luckily Lee Jay (and maybe others) found my "rant" useful. Please forgive me for not opening a new thread for making the remark that I find it frustrating that I cannot provide feedback because Adobe's "one Windows installation only" and "release without extensive testing on several platforms" policies. BTW, it's not like that obvious bugs (easy to find on all platforms) have never been included in official releases. Whether its the QC team or publication targets, this is not the state of the art in software engineering.

That is your interpretation of what a release candidate should be. Still, a release candidate is not meant to be for production work. If you need the TAT tool (which in my case does not seem to be strongly faulty, at least with HSL), you can continue to use 3.2. Release candidates are usually the last public beta builds before production. The Lightroom team has probably released the RC to receive broader real world feedback and the TAT problems seem one of them.

Besides that, many users seem to be very happay with the early release of a RC of 3.3, because this way, they can enjoy the support of recently released cameras very early.

I think we should stop the discussion about what release candidates are about because the thread should be focused about the performance issues and not if Adobe's quality control is OK.

Kind regards

Thomas

[TK2142]

tgutgu wrote:

That is your interpretation of what a release candidate should be.

Yes, and it differs from your interpretation. Whether it differs from the intended interpretion, I'm not sure, but your logic isn't very convincing:

Still, a release candidate is not meant to be for production work.

So Windows users who don't have extra machines to spare and need to do production work are excluded from enjoying the benefits of using the RC and are not in the priviliged position to provide feedback? That doesn't compute for me.

I think we should stop the discussion about what release candidates are about because the thread should be focused about the performance issues and not if Adobe's quality control is OK.

Please note that my initial post was on topic and only made a (relevant) side remark. The best option to keep the thread on topic would seem to not make such side remarks the sole topic of follow-up posts.

[thewhitedog]

Whether or not release candidate software is reliable for production work, if I recall correctly Adobe recommends against using it that way. In any event, release candidates are not finished software, or they would not be candidates. This seems so obvious to me I don't understand why people are arguing about it. The whole point, I think, of offering RC software to the public is to broaden the base of beta testers to include the widest possible variety or real world testing conditions. Adobe wants and expects to get feedback, both good and bad. Without such feedback the whole exercise would be pointless.

That said, Windows users are in an ambiguous position. Basically, if they use a RC on their production computer they are, theoretically at least, taking a greater risk that something might go wrong than Mac users, who can run the last "stable" release alongside the RC. Even so, with version 3.3RC I haven't taken the precaution of using it on only test images on my Mac. My experience since the original Lightroom beta program has given me confidence that Lightroom release candidates are reliable enough to use with my main Lightroom catalog. Others may not share my confidence; still others have found version 3 to be so troublesome that they have reverted to version 2.

Personally I think it's appropriate to believe that Adobe is acting in good faith and that they truly want to find out what's wrong with the program so they can fix it. I suggest that if you don't think they are sincere, you should not be using any Adobe beta, or release candidate, software.

[TK2142]

thewhitedog wrote:

Whether or not release candidate software is reliable for production work, if I recall correctly Adobe recommends against using it that way. In any event, release candidates are not finished software, or they would not be candidates. This seems so obvious to me I don't understand why people are arguing about it.

At http://labs.adobe.com/downloads/lightroom3-3.html there is no recommendation for not using it for production work.

The same page explains that the software has been "well tested".

thewhitedog wrote:

I suggest that if you don't think they are sincere, you should not be using any Adobe beta, or release candidate, software.

I believe that they are sincerely looking for feedback. I only expressed my frustration that -- on a Windows machine -- I cannot test the 3.3RC without giving up the 3.2 version which doesn't have a TAT problem. It is frustrating because releasing the RC with such a bug seems very avoidable. Just like some bugs in LR3.0 --  the "finished software" as you call it -- appear to be avoidable e.g.,  the one where image stacks weren't moved in their entirety but the top most image only. I appreciate that there are bugs which are difficult to find given limited access to test hardware. Some of the performance bugs seem to be of that nature. However, many bugs that were shipped with LR 3.0 could have been easily found by using systematic regression testing, including the major operating systems LR will be run on. If QC were better here, it would a) lead to more feedback for release candidates (since people would not need to avoid them because they didn't want to trade in working features for broken ones) and b) less bugs in the official releases.

[Lee_Jay-ZyZk56]

TK2142 wrote:

I only expressed my frustration that -- on a Windows machine -- I cannot test the 3.3RC without giving up the 3.2 version...

You can, actually.  You just rename the 3.2 version's folder and go install 3.3RC.

[TK2142]

Lee Jay wrote:

You just rename the 3.2 version's folder and go install 3.3RC.

That'll be cool!

Won't I get a mess in the registry, for example?

There should be some reason why Adobe doesn't suport parallel installations on Windows?

[Lee_Jay-ZyZk56]

I think there are one or two people around here who have all the past versions currently installed on Windows.  I've had as many as four versions installed using this approach.

[Lee_Jay-ZyZk56]

TK2142 wrote:

One thing that I find most surprising in LR 3.2. is that switching between images in the Develop module often causes an old preview to be briefly shown before the adjusted image is displayed. A new preview cache is only calculated if one changes to the Library module and steps through all respective images. Go back to the Develop module and now updated previews are available. That should not be necessary.

Yes, I have seen both of these behaviors consistently.  One additional thing I found that really surprised me is this.  I opened up a whole bunch of raw images in Develop, made a substantial change to all of them (major WB shift), watched each one change on my screen, then exited LR.  I then made the image files unavailable by unplugging the external drive on which they reside.  Result - the Library images show unavailable (expected) but the thumbs and loupe-mode previews were the original images.  This is related to this thread because it means the application isn't taking advantage of the rendering that is done in Develop to update the Library previews, which means one much go into library and re-render each and ever image and thumb to see the effect of changes made to the images in Develop.  This is a waste of computer resources and of time.

[thewhitedog]

When selecting an image, if I'm not mistaken, the reason you see the original briefly before the adjustments you've made are displayed is because those adjustments are never applied to the original image in Lightroom. They remain as data in the catalog. The number of steps preserved in the History panel may also affect this process. Deleting the history has been recommended (by Adobe) as one way to speed up rendering operations.

As for the "Write to XMP" issue, this requires a write operation to the original file every time you make a change; essentially you are writing the data twice: once to the catalog and once to the file; the redraw is probably connected with the dynamics of this procedure in some way. If you need the XMP data with the file for some reason (you're going to use the image in another application not directly linked to Lightroom the way Photoshop is, for instance - or you want to use the image in another copy of Lightroom on another computer), as a point of procedure, it would probably be more efficient to wait till you're done with a group of images and perform the Write to XMP operation on all of them at once at the end of your workflow.

I don't see either of these issues as a bug in Lightroom; they are a necessary element in the nondestructive image processing system the application uses. It's possible the code could be improved to run these operations more quickly, but the hardware you're using may also be a factor in how well or poorly they function.

[Lee_Jay-ZyZk56]

thewhitedog wrote:

When selecting an image, if I'm not mistaken, the reason you see the original briefly before the adjustments you've made are displayed is because those adjustments are never applied to the original image in Lightroom.

No, but they could be applied to the previews which are pulled up for a moment even in Develop while the raw data is loading and the image is being processed.  The bug or limitation is that the image has already been processed but the preview wasn't updated.

[ScottCK]

thewhitedog wrote:

As for the "Write to XMP" issue, this requires a write operation to the original file every time you make a change; essentially you are writing the data twice: once to the catalog and once to the file; the redraw is probably connected with the dynamics of this procedure in some way. If you need the XMP data with the file for some reason (you're going to use the image in another application not directly linked to Lightroom the way Photoshop is, for instance - or you want to use the image in another copy of Lightroom on another computer), as a point of procedure, it would probably be more efficient to wait till you're done with a group of images and perform the Write to XMP operation on all of them at once at the end of your workflow.

I don't see either of these issues as a bug in Lightroom; they are a necessary element in the nondestructive image processing system the application uses. It's possible the code could be improved to run these operations more quickly, but the hardware you're using may also be a factor in how well or poorly they function.

Sorry, but I disagree.  For starters they weren't there in LR2 and my PC is faster than a Ferrari.  And like many photographers, I have a variety of software packages I use that aren't necessarily as integrated with LR as Photoshop is.  I never had an issue with any of this in previous versions, just from v3 onwards.

[PhilBurness]

Perhaps Adobe could confirm (or update) the minimum requirements for running this software efficiently / effectively if the processing demands have risen significantly?

appcoop1 wrote:

Tom,

Aside from trying to analyze everyone's individual issues and system configurations, can we agree that many of us are using the Same systems with Lightroom3.x as we were using with 2.x and are now having varyied performance issues?

I trust you are looking at coding changes that have been made since 2.x as well as additional features added to 3.x ? That would seem a likely starting point.

Regards,

Karl

Phil

[Jasonized-nfnCsn]

Karl,

    in responce to your request, I was running the same hardware for 2.7 and was having no issues.  When I moved to 3.x, I was forced to double my memory from 8gigs to 16 gigs in order to get any time running at all.  I recently (last two weeks) upgraded my OS from 10.5.8 to 10.6.5, and had no change in the symptoms or solutions.  I had no issues whatsoever with 2.7, or even with the beta 3.0 (that I noticed).

Cheers!

[DdeGannes]

I am a user of Lightroom since the Beta v3 before the release of V1. I have always upgraded to the latest version up to the present version LR 3.3RC.

My main operating system has been Win through XP to Vista and now to Win 7 64bit.

Info on my existing system is as follows.

I have followed the forums since the use of the original Lightroom betas and while I have not experienced any major problems I can accept that some users experience major performance issues.

My main use of LR is for developing my raw files from Olympus E300 and E510 and I must say that the improvements over the past few years in the process engine, particularly process version 2010, has been very good. During this development period of Lightroom I have also used and continue to use several third party raw processing software including SilkyPix  versions 2 through 4 and Bibble Pro versions 4 and 5. These products all have their individual strengths and produce very good/excelent output files.

Presently I use Lightroom as my main raw processing software but I recognize that the processing of raw data from Digital Cameras is still in a rapid development stage. The main reason for the use of Lightroom is the quality output of version 2010 and the improvements to the sharpening and noise reduction features in version 3.x.

[Jasonized-nfnCsn]

Greetings Tom,

   I still see swapping/memory issues when viewing/rating quantities of images ( > 500).  LR does not appear to reuse preview memory; exiting the program and restarting does not "solve" the issue.

   I too have been an LR user since early beta release pre-1.0.  My machines have increased in power the entire time; and they have switched back and forth between PC and Mac.  Right now, I'm running a dual-quad core Mac Pro, 16gig of ram, internal SCSI Raid arrays and Nvidia Quadro FX5600 display driving two Eizo 24" monitors.  I have recently upgraded from 10.5.8 to 10.6.5, with no change in the symptoms, so does not appear to be related to OS version.

   LR can not handle importing and sorting a days shoot of images without having to stop and reboot the machine partway through because 16 gig of memory is not enough.  If I am spending the day editing only a few dozen images, arranging collections, cropping, etc, then there is no problem.  It appears to be previewing (or some relation to it) that causes the problem.

  I can reproduce this issue without effort (just a bit of time to page through 500 images) repeatedly.  Some where around 500 images, every 3rd image will cause a page fault and swap starts growing.  This is silly!  I understand if you wish to keep memory around for images that you have already seen, it speeds things up.  But when you reach the point where you start swapping rather than reusing memory, you are losing far more than you gain!

  In other problems, I too tend to do heavy retouching in PS, because I have noticed that a lot of spot corrections ( > 100) cause the response to slow down massively.  To the point where I click and wait a couple of seconds before another dust correction circle shows up.  So for images that have a lot of dust (I had one set that i was shooting a harvest, dust everywhere, darn it!) I do what I can in LR, as far as corrections go, then export to PS so it doesn't kill off LR.  But of course, doing that, I lose the raw functionality.  Ah well.  Not sure if that is an actual issue, since 99.99% of my images don't require dust correction like that; just mentioning it if you think it is an issue.

Cheers!

[thewhitedog]

To follow up what is still cropping up on the old thread, I agree with TK2142's latest post that Lightroom 3's default balance of real to virtual memory seems to favor older computers with limited RAM. But limited RAM is of diminishing importance these days, even on laptops, where 8 GB is not uncommon. As a result, the program cannot make efficient use of systems with plenty of RAM available. Designing for the lowest common denominator seems to me to be a short-sighted strategy at best. For some time now Photoshop has enabled people to allocate resources according to their own workflow needs. Indeed, Photoshop CS5, in 64 bit mode, finally enables us to access more than 3 GB of RAM. Likewise, it has been possible for many years in Photoshop to designate the drive to be used for application swap files (virtual memory). In my not so humble opinion, users would benefit immensely from such capabilities in Lightroom. Certainly many of the problems people are reporting on these forums would be less severe if Lightroom could be directed to better utilize available resources. I can't imagine this issue hasn't occurred to the Lightroom engineering team. Apparently, though, they are reluctant to address this matter. I suspect perfecting the code alone cannot solve all the reported performance problems. We need the same kind of flexibility in allocating resources for Lightroom that we enjoy in Photoshop.

[John_R_Smith]

On my Win 7 box, I monitored memory usage when I first installed LR 3.0 and subsequently 3.2. LR 3.0 did use all the available RAM (4GB) when processing large files with lots of adjustments (perspective control, local brushes etc). Now, LR 3.2 does not, but seems to page out to disk over about 2.4GB. So something has changed.

John

[ScottCK]

I'm still seeing significant performance issues with the 3.3RC, which I've previously reported in a bug report.  I have my catalogue on a 2 drive mirrored array and if I leave Write to XMP turned on in the preferences, every change I make to a RAW/TIF image causes a full screen refresh.  As soon as I turn off the write to XMP option the problem goes away but then I have to hit Ctrl-S for every image I make changes to.  It was never an issue in LR2.

[Jim Stamates]

I haven't searched to see if anyone else has this experience and I'm not sure what the cause is.

MacBook Pro 2.33 3gig ram

3.3 rc

Two problems:

When I use the right and left arrows to scroll the film strip, and I hold down the arrow for a few seconds, after I release, it continues to scroll until the end of folder is reached. I hit the opposite arrow to try to stop the auto scroll, sometimes this stops it, sometimes not.

2. If I click on a folder in either the Collections or in the Folders it may take quite a while (I know, vague) to see images. 'loading...' is all I see for up to a minute?

Also, if I select 2 folders to search, LR will sometimes crash.

Been using since LR1 beta. Cat. size is around 60K.

All images on external drive. All cats on main drive in MBP which is 500gb.

Thanks for listening.

[JW Stephenson]

Tom,

Thanks for starting a new thread.  Hopefully we can all keep this thread to constructive feedback.  I also posted this information on a similar thread relating only to the spot healing tool so sorry for the duplicate information.

I am running W7, 64-bit, 12GB RAM separate, internal raid arrays for OS, Cache and Images, and dual quad-core processors with hyper-threading.  I designed the machine specifically for LR 2.  Still, with both 2.5 and 3.3RC loaded for testing, the time to process images is at least twice as slow for me in 3.3RC and that is without problems with the spot healing tool.  This is a non-scientific measure of how long I am sitting at my computer to finish a set of a similar number of images.  If I have scans with many spots utilized, the cost in performance is exponential relative to 2.5.  Everyone's machine is of course different.

I have filed a bug report for this when 3.0 first came out and have been in contact with Adobe providing information to help isolate the problem.  Adobe did improve the problem with 3.3RC (at least for my machine) in that it is now less likely to freeze, but it still slows down to a point where the spot tool is unusable after a large number of spots are implemented.

Recently I opened a CPU monitor to watch when doing spot healing and noticed that when it "hangs" only one of the 16 cores is being used (other than a couple at say <5%) and it is stuck at 100%.  When the spot tool become useable again, it is immediately after the core usage drops below 100% again.  It is as if the multi-core ability of LR somehow fails when using the spot tool and therefore it becomes a noticeable problem when a large number of spots are placed on a single image.  Not very scientific but may be a lead.  I also find that it hangs more likely when accidently changing the size of an existing spot when intending to add a spot instead.

In any case, LR is my product of choice and I am patiently awaiting 3.3 or 3.4 to get some performance back.  With the number of views on the old thread and the probably number of posts and views here, I have to assume that Adobe is still working on this issue.  Having the noise reduction overhaul of 3.0 is the feature that keeps 99% of my images non-destructive and thus I am not likely to return back to 2.5 unless Adobe simply states that this issue cannot be resolved - in which case I will have to consider that possibility.

Also, some have suggested that hardware might be an issue.  If indeed it is a component of my hardware that is no longer compatible when moving from 2.x to 3.x, I am more than willing to change-out that component - just need a little insight as to what to replace

Jeff

[JayS_In_CT]

Memory Allocation Issue.

Tom,

I'm on a Macbook Pro, 2.1 with 4GB RAM installed (gains dual memory optimization and some additional real above 3GB limit).  Just started LR 2.7, CS5 Extended, Bridge for CS5, and LR 3.3.

Looking at Apple Actviity Monitor I see the following:

LR 3.3  1.16 GB Real  1.30 GB Virtual - One 7D image Processed and Exported to JPEG

LR 2.7 557.1 MB Real  727.9 Virtual - Same 7D image (different catalog) processed and exported to JPEG

CS5 Extended  276.1 MB Real  272.0 Virtual - Exported Image basic USM filtering

Bridge CS5 - Launch CS5 Extended - 70.7 MB Real 77.7 Virtual

Firefox (Idle) - 89.9 MB Real 83.7 Virtual

Not sure why the added Memory Footprint by total of 1 GB (combined) for LR 3.3?

Jay S.

[Averil2]

I wasn't going to download the LR3.3 until it officially came out but I just acquired the new Nikon D7000 and I found myself having to download the 3.3 so that LR could read the RAW files. It worked beautifully for that but when I tried the Camera Calibration under Develop the only choice I had was Adobe Standard and I was shooting in RAW. Did anyone else have this problem and is there a fix?

[Lee_Jay-ZyZk56]

Averil2 wrote:

I wasn't going to download the LR3.3 until it officially came out but I just acquired the new Nikon D7000 and I found myself having to download the 3.3 so that LR could read the RAW files. It worked beautifully for that but when I tried the Camera Calibration under Develop the only choice I had was Adobe Standard and I was shooting in RAW. Did anyone else have this problem and is there a fix?

This is not related to this thread, but the fix is probably to wait for the full release.

[Averil2]

It says performance feedback. That is what I was giving