Lightroom 3.3 Performance Feedback

Hi,

FYI.

I just did some testing with the recently announced Cyberlink Photo Director, a (shameless) clone of Lightroom. Regarding performances when using local adjustements, in all honnesty, I must say that it is not faster than LR. It might even be slower in some cases. Importing is significantly slower in Photo Director.

Local adjustments continue to perform faster in Camera Raw than in LR, though. So either LR and Photo Director have the same problems (in that case Photo Director is actually a "real" clone) or it's time to setup a much more powerful workstation to get LR (and its clones) running at a speedier pace.

--

Patrick

I have discovered an interesting "tell tale sign" of the performance issues I have had.

Most of the time (in Library mode) LR3.3 and 3.4RC are very sluggish when moving from one image to the next (as in, it takes SEVERAL SECONDS to use the left and right arrows to move back and forth between images).  HOWEVER, I had found that some times it seemed very speedy (about the same speed as LR 3.2 and previous releases).

I believe I have discovered why.

BACKGROUND INFO

-------------------------------

For speed purposes, my catalog and previews are on an SSD and all images are initially copied onto a local drive.  I do all of my processing locally (backing files up to a very large DroboPro as I go).  Later on, when a particular session is no longer "active" (proofs have been posted, orders have been filled, or it appears it may be awhile before the customer places an order) I will DELETE the images from my local drive to make room for incoming sets from other photo sessions.  That's okay, all of the images are still out on the Drobo.

Because I have been "backing up" the whole time ... the way I clean up the local drive is very simple.  I simply delete the images.  There is nothing to move, nothing to change.  I just delete the images.  In Lightroom the folder simply becomes disconnected.

LATER, when the customer places an order, I will go to the folder in Lightroom and tell Lightroom I want to "reconnect" the folder and then point it to the location on the Drobo where that folder exists.  Lightroom has kept all of the previews in the catalog and this is a very quick process. 

I've been working like this (or in similar fashion) practically since LR 1.0 came out.

-------------------------------

So here is what I found: 

Sometimes (not very often) I am working without the Drobo connected.  I recently noticed that is when LR3.3 and 3.4RC move very fast (sub-second times to switch between images)! 

In fact, to prove this to be the case ... I have recently processed several of my incoming photo sessions without the Drobo being attached and in every case the performance has been good.  Later on, again to prove a point (and because I needed to take care of the backup), I have plugged in the Drobo and tried LR again and noticed that the speed has, in fact, suffered once again.

So here's what I think is going on:  I have a LOT of "missing folders" in my catalog.  They remain missing either because I fulfilled the customer's order and deleted from the local drive without ever having to re-attach the Drobo-sourced location to the catalog, or because the customer is taking a really long time to get back to me. 

MY GUESS is that while the Drobo is attahced, LR is out there scanning for missing folders.  Could it be?  (I don't think it has ever reconnected any folder on its own - I'm just guessing that LR for some reason is looking at my Drobo)

When the Drobo is not attached, there are no external drives to scan.  LR is fast.  When the Drobo is attached, there are probably well over 200,000 raw images in thousands of folders and I'm guessing this is not a happy place for Lightroom.

I've been wanting to download the SysInternals File Monitor to test out my theory and just haven't had time yet.  But in the mean time, I thought I'd pass this idea along and let your developers think it over.

Thanks,

David

OK, i've come back on because siunce the upgrade to LR3.3, my Mac has started grinding to a halt again in, and when trying to exit, develop module.

We're almost back to the same position as LR3.1 - and that almost forced me back to LR2!

It seems like plenty has been written, and i appreciate that various comp configs will affect how a prgoram works - but i'm puzzled by the fact that Mac's are, for the most part - all built to a same spec, where as Windows systems reqlly can vary from one pachine to another.

Sad things, my Mac is already maxed out at 4gb, and i'm in no hurry to ask for funds to upgrade to a model that can accomodate 16gb of ram - shouldn't need to...

Will have to keep an eye on this issue, and roll back to RC3.2 if a fix doesn't happen soon...

web-weaver wrote:

> "What are your settings for Autoplay for the card reader?

> On all my drives - including the card reader - I have Autoplay disabled, i.e. it is set to

> "Take no Action"

I also have Autoplay disabled. As a test; I turned it on and had Pictures set to import into Lightroom 3, but that did not help either.

But, I finally figured out a workaround for the performace issue on my system when importing to the Lightroom 3 library module. My 75-in-1 internal memory card reader (Rosewill - RCR-IM5001) sits in a 3.5" drive bay, on the front of my pc case. As it shows up in Vista as a 'USB Mass Storage Device', I can go into the Device Manager and set it to 'Disabled' before I click the import button in LR3. Thus, the import dialog pops on the screen very quickly, but without the drives that would have been available through the card reader. Later, I can go back into Device Manager and re-enable it.

I can live with this workaround for the time being. I usually copy my files from the card reader to my Photos folder beforehand, anyway. I just hope these import-related card reader issues get resolved sometime in Lightroom 3.x.

Thanks to everyone who replied here or posted about card reader issues in the other forum threads.

Hi,

Here is a copy of a report that I just sent to Dan after I had new LR performance issues on my system. I'm wondering whether other users have the same feeling and are observing the same symptoms...

I recently worked on a few images in LR (3.3) that needed lens corrections (mainly vertical and horizontal transforms) beside the usual corrections. While I was trying to set the relevant sliders, LR suddenly started to misbehave, slowing down to the point where it was totally unresponsive and unusable, displaying blank screens for a while, etc.

I copied the RAW file and the XMP file to another folder and loaded the image in Camera Raw. Working there and trying to apply the very same corrections was a much smoother process. No slowing down, no misbehavior. Well, transforming a rather big image takes time but at least I could do the job without any particular problem.

Not a new topic but I was again wondering why there are so much performance inconsistencies beween LR and ACR. Then I noticed that the ACR and LR user interfaces are actually not working the same way. For example, when I move the horizontal transform slider in ACR, it seems that ACR stops any computation until it detects that the slider is no longer moving. In LR, it seems that these computations occur continuously. That is, as soon as the slider value is changed a new computation is started. But the user can still increase or decrease the value while LR computes the new image. As soon as this computation is terminated, LR detects that a new value has been set and starts again. Meanwhile, the user can set a new value for the slider, etc. I don't know if I am clear enough but I guess you see what I mean. ACR obviously doesn't behave this way.

My feeling is that LR doesn't have an internal flag telling him that the current computation is no longer valid and has to be stopped because the user has changed the slider value anyway. It seems that ACR has such a mechanism. Otherwise I cannot understand why ACR runs much more smoothly when doing exactly the same job as LR. Moreover, if these transform computations are managed in a queue and if any change in the slider value adds a new entry to the queue (thus generating a number of useless jobs), I can understand why LR becomes unresponsive : a lot of unnecessary jobs are stacking up in the queue and are executed while they should be invalidated each time the user changes the slider value. Just a guess but there must be an explanation anyway...

Hope this helps.

I'm having major performance issues on my system with LR 3.3 & LR 3.4rc. I have looked through the previous posts, but haven't found anything that looks like this. If somebody has seen and resolved similar problems, please point me in the right direction.

When start Lightroom & click IMPORT, here is what I get:

• Select Source screen @ 0:31 (31 secs).
• Select Source screen is populated (hdd's shown) @ 2:17 (1m,46s).
• My 'Pictures' folder finaly displayed @ 2:45 (28s).

Then, after clicking cancel, it took 26 seconds to get back to the main Library screen, and ready to import again.

So far I've tried uninstalling, cleared all Lightroom registry entries, and did a fresh install. Same results.

All of my other apps, including Photoshop, work fine and perform well. Any help would be greatly appreciated.

PS:  Here is the paste from my System Info dialog:

-----

Lightroom version: 3.4 RC [733717]

Operating system: Windows Vista Service Pack 2 (Build 6002)

Version: 6.0 [6002]

Application architecture: x64

System architecture: x64

Physical processor count: 4

Processor speed: 3.2 GHz

Built-in memory: 8189.2 MB

Real memory available to Lightroom: 8189.2 MB

Real memory used by Lightroom: 131.1 MB (1.6%)

Virtual memory used by Lightroom: 124.6 MB

Memory cache size: 0.0 MB

System DPI setting: 96 DPI

Desktop composition enabled: No

Displays: 1) 1920x1200

-----

MSI MS-7577 Motherboard

AMD Phenom(tm) II X4 955 Processor

ATI Radeon HD 4850 X2 Graphics Card w/ 1-GB RAM

I'm looking for help about persistent performance issues I'm having with Lr v3.3.

I've been using Lr since v1 and have loved the program but I continually have performance issues with v3.3.

Description of the problem:

I'm editing CR2 files that have been converted to DNG. They're all large raw files from a Canon 5D mk2. Currently I'm working on a brand new 15" MBP (core i7, 8GB ram, 1GB dedicated graphics memory, etc) but have also experience the same issues on my 13" MBP - two fully capable, functioning machines. Lr v3.3 regularly freezes up while working in the Development module. Usually seems to be when I'm using the lens correction tools. Once the Lr freezes up and I see the mac pinwheel of death, it's all over. Force quit, restart, new catalog, accessing the raw files for the local drive, etc nothing works. I've uninstalled Lr and reinstalled yet the problem has popped up again.

This is crippling to my workflow. I cannot consistently edit because Lr locks up. Is anyone else experiencing a similar problem?

Please advise.

Hi,

So Adobe wants user feedback in order to fix these performance problems. But are they doing what is needed to achieve such a result?

In every commercial application I have ever written, I have always implemented a "debug mode" feature. When a user reported a problem that I could not reproduce in my lab, I asked him to open the application's "Preferences" dialog and to check the "Debug mode" option. With this option enabled, the application started to record every user actions, tracing entry and exit points (and exit codes) of every important routine, collecting information about the user's system, etc. Once the problem had occured again, the user had to disable the debug mode option and to send me the log file. 90% of the time I could see what happened and fix the problem (or explain to the user what he was doing wrong or what was wrong with his system) without having reproduced the problem on my own systems. And I'm not talking about small applets. I implemented this in complex applications involving a user interface, system services and device drivers. By the way, this demonstrates that the statement "not reproduced, not fixed" that we have read here too many times is not justified.

If I was able to do this for my apps as a small software shop, I'm wondering why Adobe can't do that for Lightroom. There are a lot of commercial software on the market having a similar option. Of course, such a feature is a little bit more difficult to add "after the fact". It's preferable to think about it during the software engineering phase. Also, when the application uses multithreading (like LR does), the logging system has to be protected against re-entrancy. But any seasoned programmer can deal with this.

When implemented properly, such a feature has no impact on the software performance. When the option is disabled, the debug code does nothing at all. When enabled, this code may slightly affect performances but again, if this is done properly, the impact will be very limited.

If we go back for example to the "frantic registry accesses" problem, a debug mode feature would have help determine what's going on (which code is running repeatedly) when the problem occurs.

So I'm wondering : since LR version 1.0, bugs have been reported that Adobe could not reproduce and nobody has ever considered implementing a debug mode feature or writing a specific debug version (which is another way of achieving the same result : collecting information from and tracing execution on the user's system) ?

@ TK2142: If you don't want or need everything Photoshop can do, or a reasonable subset of it that would make the price a practical expense, you might take a look at Photoshop Elements. For under $100 you get an app with many of the most useful features of Photoshop without all the overhead. If I'm not mistaken, you can access Elements just as you do Photoshop out of Lightroom because it, too, uses a current version of ACR. What I don't know is if it support Smart Objects. I'm sure someone on this forum can speak to that.

But Smart Objects are the way around the destructive editing you are concerned about with Photoshop. In effect, a Smart Object includes a copy of the original file you edited in Lightroom and opened in Photoshop. You can, therefore, edit that Smart Object with ACR even after you've opened it - and saved it - in Photoshop. I don't know why this solution isn't publicized more widely because it seems a dream come true to me. If you right-click over an image in Lightroom you will see among the options in the contextual (pop-up) menu the item Edit in; the fly-out menu from that includes Open as Smart Object in Photoshop. I haven't used this technique much so I can't speak to all the issues involved but it appears to me to be decent way to preserve access to your Lightroom settings in the context of a Photoshop file.

Your unwillingness to deal with more than one version of a file, on the other hand, seems both arbitrary and unreasonable. If you need the functions for which Photoshop is more suited, multiple files are a small price to pay for the flexibility they give you.

Instead of setting out a list of more or less random demands, you should look at your work from the perspective of desired results. Choose the results you want and then select the tools that can most effectively produce those results. It's simply the case that if Lightroom cannot provide everything you need to get the results you want in an efficient manner, you will need to consider adding additional tools to your repertoire.

In the meantime, for those having trouble with Lightroom, we can either dial back our work strategies to fit into what Lightroom can do, and hope that the issues we have with the program will be resolved eventually. Or we can look elsewhere for an application that does the job with fewer hassles. Since Apple has dropped the price of Aperture so drastically, it's become a far more attractive alternative to Lightroom. There are other options, like Lightzone to consider as well. Of course that means learning how to use yet another program, but for some it may be the better, even a necessary choice. This is especially true given the disappointing list of fixes (and the new bugs) in the LR 3.4 RC. I'm sure I'm not the only one who feels their trust and patience have been betrayed. This feeble list suggests that fixes for the serious performance problems that many people have with Lightroom will not soon be found. From a user perspective it doesn't matter why these problems have not been addressed, especially given that we have no way of knowing why. It only matters that they have not been - and that we no longer have a reasonable expectation that they will be, given how close-mouthed Adobe staff are about what they are actually working on. Yes, they have their reasons for so much secrecy, but there is a price to be paid for that secrecy in declining customer satisfaction, trust and loyalty. In the end it doesn't matter what Adobe's policies and priorities are. It only matters that solutions have not been forthcoming.

Well, the thread left - partly on my fault - the intention Tom Hogarty originated it for: to supply useful information about performance issues. Now, we are again in the mood to discuss, if it is the majority, who faces problems, or if it is the minority.

With regard to the last posts, I have to second Jeff Schewe, that Lightroom works mostly as expected. In general, it is stable, fast, suitable for its tasks. How far we can get with parametric editing, depends obviously on factors, not fully understood, but based on my own experience the architecture and code quality is at least so good that it works flawlessly in general in my environment.

I have upgraded to a new camera (GH2) with larger files, and a much higher resolution monitor (2560 x 1440), have increased and recreated the standard preview size to 2048 pixel, and have yet to find any point where performance has degraded due to this changes. In fact, subjectively, I find that editing is even a bit smoother now, brush strokes and spot healing work well.

My point was rather, that acknowledged and reproducible bugs and issues, don't get attention in visible results, and that no follow up communication takes place, even if the bug was acknowledged publicly here. So it is always a lottery game for the user, once a new release is announced: will my issue be fixed?

If things aren't fixed in a new release, I think it is fair enough for users to ask about the whereabout of the clearly described and reproducible bug, and to remind the developer team, to fix it. As long as the communication works as it is, this is the only way for a customer to ask for progress.

My specs:

Windows 7 64-bit Home Edition, 4 GB RAM, Intel i5-750, 2.67 Ghz CPU, Nvidia GTS 250 graphics card.

Monitor: EIZO SX 2762W (2560 x 1440)