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

[thewhitedog]

You are right up to a point about Photoshop. But it has it's own ways of adding processing overhead, including history states, layers, effects, channels and so on. In addition, Photoshop is not only a pixel based program. It can handle vector elements in text and Smart Objects, including those generated from Lightroom files. And Photoshop has huge cache requirements given the large files people work on these days. Indeed, there are those I know who experience the same kind of lags and slowdowns using recent versions of Photoshop and Bridge that we see on this forum in respect to Lightroom.

These days any computer with less than 4GB of RAM and at least four CPU cores will have trouble handling more than one of the latest versions of Adobe's apps at a time.

[web-weaver]

thewhitedog wrote:

Indeed, there are those I know who experience the same kind of lags and slowdowns using recent versions of Photoshop and Bridge that we see on this forum in respect to Lightroom.

Yes, that is so. In PD CS5 I experience a similir slow-down and unresponsiveness when using the clone tool for 100s of clone points or when using the paint brush on a mask. "Purge Cache" restores these tools to their initial speed and responsiveness.

In this respect I wonder if a "Purge Cache" feature would be (a) possible and (b) helpful in LR to restore responsiveness.

I don't know enough of the "innards" of LR to give an opinion but maybe Jeff Schewe and others could and would?

WW

[thewhitedog]

You can purge your history one file at a time, which has been recommended to improve performance. However, I don't think Lightroom caches as much data as Photoshop so I doubt it would be comparable.

[Jeff Schewe]

thewhitedog wrote:

You can purge your history one file at a time, which has been recommended to improve performance. However, I don't think Lightroom caches as much data as Photoshop so I doubt it would be comparable.

The History in Photoshop is completely different than the History in Lightroom. In Photoshop, the History is part of the scratch file and stored on disk. PS's History is a real time cache of the actual pixel changes and that can indeed take a lot of HD space. Lightroom's History is really just a list of changes not the actual pixels. So it takes a lot less storage in the database.

Lightroom's History is also persistent-meaning stored in the database, image by image and even after Lightroom is closed. Photoshop's is temporary and is lost when you close an image. I really don't think Lightroom's History is at all involved in the slowdowns some people are seeing so I wouldn't suggest clearing LR's History (unless you really don't want to keep the History of what was done to an image).

[thewhitedog]

I wasn't comparing Lightroom's history and Photoshop's history. Also, whether or not purging the Lightroom history will help performance rather depends on who you ask. Better authorities than I have suggested it might. But, as I said, it's not comparable to cashes in Photoshop, which was what the original question concerned.

[web-weaver]

Thanks, Jeff.

I don't doubt what you're saying, Jeff, but I wonder why it has been suggested on this forum by several posters to make the LR Cache size very large.

WW

[Lee_Jay-ZyZk56]

web-weaver wrote:

Thanks, Jeff.

I don't doubt what you're saying, Jeff, but I wonder why it has been suggested on this forum by several posters to make the LR Cache size very large.

WW

The Camera Raw cache stores partially-processed raw images in such a way as to make the further processing necessary for actual editing in Camera Raw or Lightroom much faster initially.  If the cache is populated with these partially processed images, switching from image to image in Develop will be faster and you'll be able to start editing faster.  The cache size essentially determines how many such stored image it can contain.  If you are, for example, working on a shoot of 500 images and the cache is set for 100 images, when you render your previews only the most-recently processed (I think - Jeff or Eric can correct me here) images will be in the cache and you won't get any benefit if you aren't switching to one of those.  Of course, if you do switch to an un-cached image, it will be slower but then it will be added to the cache and will be faster if you move to another image and then back while it's still in the cache.

[TK2142]

Lee Jay wrote:

...Jeff or Eric can correct me here...

I'm neither Jeff nor Eric but what you write about the ACR Cache (which is also used by LR) is exactly right.

[areohbee]

TK2142 wrote:

...but what you write about the ACR Cache (which is also used by LR) is exactly right...

Granted, thats a best-case scenario.

The ACR cache handling is a source of some bugs, so beware. Some have reported Lightroom performance (severe degradation) tied to standard preview-size, which also affects cache entry size (I dont understand why), and often in an manner that is really bizarre for lack of a better way to put it. For example, cache entry sizes for my D300 follow this curve:

Preview Size -> cache entry size:

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

1024 -> small

1440 -> bigger but still small

1680 -> huge

2048 -> medium

Others have reported similarly bizarre curves - different for different cameras. Still others have reported more expectable/normal curves, like:

1024 - small

1440 - bigger

1680 - medium

2048 - large

If everything were working OK, I'd chalk it up to yet another thing I dont understand, but ACR cache is useless to me (no detectable speedup with cached entries - I disable it completely by changing permissions so file creation is denied), and as I've said, others have found huge performance differences (of the bug variety - like differences that should make it a little faster instead are making it an order of magnitude slower) simply by changing the standard preview size.

R

[areohbee]

web-weaver wrote:

...I wonder why it has been suggested on this forum by several posters to make the LR Cache size very large.

In theory, the larger the ACR cache, the more likely you'll get a "cache hit" (cache entry still exists) when switching to a different photo in Develop mode, and the faster the switch will be in that case. In practice, YMMV.

[web-weaver]

Thanks Lee Jay and Rob.

From what you guys are saying, I gather it would be counter-productive to purge the cache in LR.

WW

[areohbee]

My recent bout of ACR cache testing resulted in complete disablement (by denying write permission). It made me a little queasy to do it, but the results of my tests were clear: it was doing no good. I tried re-enabling it when 3.4RC came out - no improvement. I'll try again Lr3.4, and Lr3.5..., -but its never been acknowleged by Adobe and will likely not make the "bugs fixed" list.

I really dont know whether its completely broken (for me), or just doesn't do any good because its no longer in the critical path bottle-neck-wise, but the strange cache size entries tied to the standard preview size make me leary...

PS - There may be some value in purging the cache, for testing purposes, but if operating normally - I cant see a reason.

R

[TK2142]

Jeff Schewe wrote:

...if you want to understand the fundamental differences between "pixel editing" and "parametric editing" then you have to understand from where Lightroom came.

Not to be nitpicky but, no, I don't need to know where LR came from in order to understand the difference between destructive editing ("pixel editing") and non-destructive editing ("parametric editing"). There is a difference between "non-destructive editing" and "parametric editing" but this difference doesn't matter here.

I'm not sure whether you are reading my posts in full or just selectively. I'm a software engineer. I can program. I not only know the difference between "pixel editing" and "parametric" editing, I know how the respective programs differ internally.

Jeff Schewe wrote:

(adjustment layers defer the processing until you flatten).

Adjustment layers don't defer the processing. Otherwise you wouldn't be able to see their effect before you flatten layers. Adjustment layers prevent the destructive part of editing from happening, if you want you can say they "defer the destruction", but the latter only makes sense with an underlying assumption that layer flattening is what one wants to eventually do. There is no conceptual difference between PS managing its adjustment layers (and their parameters) and LR (ACR) managing its local adjustments. In both cases, the parameters (metadata, if you like) for an image manipulation have to be stored, previews are computed on the fly, and the final rendering of an image (e.g., for printing) takes some time.

If PS can do it efficiently, LR can too, no? The layer masks of PS and the adjustment brush strokes of LR are not to dissimilar (both are used to control the effect of adjustments, layer masks don't capture strokes but strokes could be used to create internal masks).

Jeff Schewe wrote:

In Lightroom (and ACR), the edits don't actually happen when the spots are places...the edits are stored in metadata as parametric edits that are deferred until actual processing (exporting).

If that were the case, you couldn't see the effect of the edits interactively. At least the effect on previews needs to be calculated. All those editing effects are incremental, i.e., there is no need to replay the entire editing history. Only the latter would result in a slow done linear to the number of edits. Given the fixed rendering pipeline of LR it is not quite as easy as just calculating an incremental effect on top of what has already happened to the image, but still, with appropriate optimisation techniques, the slow down in editing need not be linear to the number of previous edits. Can you please accept this from someone who knows how to program?

Jeff Schewe wrote:

Massive retouching and image compositing simply isn't in the cards for Lightroom because of the original "Shadowland" design decisions...it's really an either/or situation.

Here's a statement that makes as much sense: "A large number of adjustment layers isn't in the cards for PS because of the original "Shadowland" design decisions."

First, the original "Shadowland decisions" don't come into this at all. Potential limitations of parametric editing might be a factor but I'm claiming there is no fundamental problem that could not be addressed by optimisation techniques.

Second, any non-destructive image operation in PS (e.g., adjustment layers) would fall under the same limitation. Is that the case? Are you telling me that in order to work with PS efficiently I have to always flatten layers? If PS can support non-destructive editing efficiently, LR can too. Does that make sense?

[TK2142]

Jeff Schewe wrote:

This is really the line in the sand. Do you edit the parameters or edit the pixels.

I asked you a question about PS's efficiency with multiple adjustment layers. Does PS get bogged down by many adjustment layers? Did you read the respective post? If so, do you now accept that the performance differences between PS and LR in terms of editing speed (not rendering/processing speed) are not mandated by different "pixel editing" vs "parametric editing" paradigms?

If I believed, as you did (and maybe still do), that LR cannot support substantial edits on single images for fundamental technical reasons then I would argue the same way as you ("horses for courses, use PS & LS what they were designed for"). However, I know that there are no fundamental technical reasons stopping LR to become an efficient image editor.

Remember when you tried to explain to me (~ June 2010) that it would be technically impossible to support a clone brush because LR isn't based on the "pixel editing" paradigm? Do you still believe that?

We have to accept if Adobe says "We are offering two programs that have slightly overlapping functionality but if you are dealing with many images and occasionally have to considerably edit a single image then you need both programs". What we don't have to accept is an explanation that says "this is because of technical reasons". If portrait photographers will indeed be forced to suffer the downsides of dealing with two applications (see my earlier list) then because Adobe wants it, not because they cannot fix it.

As you know (and told me before): What is in LR's Develop module (e.g., the fact that there currently is no good cloning/healing/retouching support) is dictated by what is in ACR. What is in ACR is largely dictated by Thomas Knoll. If this is true -- and you told me it is -- then there is a problem for LR because LR developers cannot add cloning/healing/retouching on top of ACR, they have to rely on what is in ACR. But if Thomas Knoll is primarily interested in PS he has no need to add anything to ACR.

This is where I believe LR's problem is. It depends on what happens to ACR (not only in terms of ACR functionality but also performance) but ACR's development is not driven by LR needs but mostly by PS needs. Hopefully I'm not completely right and we'll see a future ACR that caters more to what LR needs.

[DdeGannes]

The reality is LR is designed to be an alternative to ACR / Bridge not as an alternative to Photoshop CS. Lightroom is ACR with file management capabilities using a data base structure and some other tit bits.

[ChBr02]

All of this history lesson is fascinating.  NOT!

Fact Lr 2.7 was a very usable product.

Fact Some people found Lr 3.0 Beta to be at least as fast as Lr 2.7, but then Lr 3.0 to be significantly slower even though Adobe advertised it to be significantly faster.  WHY???

Fact Some people still find Lr 3.3 / Lr 3.4RC to be unacceptably slow.  For me unacceptable is having the sliders not work in a smooth continuous fashion.  They worked fine for me in 2.7.  I now have to guess at a value, and then wait for the change to take effect.  Then I try another value.

PLEASE, PLEASE, PLEASE, take this historical blog, and technological bickering somewhere else, and let those who have performance problems, and/or solutions use this forum.

I talk to a lot of people who use Lr and/or Aperture in photography, and Adobe classes. I haven't talked to very many that are happy with Lr3.x.  Many Mac users now only use Lr for cataloging.

I have several XP & Win 7 platforms, and all have performance issues.  Plus, I get the occassional hang that could last for up to a minute.

Adobe, please find several platforms that are working well (if any) and similar ones that aren't and try to figure out how to fix the performance issues.

I can't imagine some of the longwinded on here worrying about performance issues when they have so much time to post irrelevant things with which to burden us.

[TK2142]

ChBr02 wrote:

PLEASE, PLEASE, PLEASE, take this historical blog, and technological bickering somewhere else, and let those who have performance problems, and/or solutions use this forum.

I hear you but the performance issues you have listed are as well-known as the response you find on this forum which is: You are experiencing problems that only affect a minority. It is not feasible for the small LR team to reproduce or fix these problems. Live with it instead of baying at the moon and/or ranting on this forum. It is not a response that I find acceptable but what is the point of provoking it time and again? Keep submitting your bug reports, there is nothing else you can or should do. At least that's what I've been told.

[Jeff Schewe]

TK2142 wrote:

If I believed, as you did (and maybe still do), that LR cannot support substantial edits on single images for fundamental technical reasons then I would argue the same way as you ("horses for courses, use PS & LS what they were designed for"). However, I know that there are no fundamental technical reasons stopping LR to become an efficient image editor.

Well, Lightroom hasn't changed from being a parametric editor, so yes, I sill believe that Lightroom prevue continues. Substantial imaging involved with retouching, layers, compositing–the things that Photoshop is designed for–won't be put into Lightroom because it's not technically feasible with the parametric editing paradigm. Could Lightroom force fit a pixel based editing module into Lightroom? Yes, I suppose but the interest in producing yet another pixel editing tool is simply not there.

TK2142 wrote:

As you know (and told me before): What is in LR's Develop module (e.g., the fact that there currently is no good cloning/healing/retouching support) is dictated by what is in ACR. What is in ACR is largely dictated by Thomas Knoll. If this is true -- and you told me it is -- then there is a problem for LR because LR developers cannot add cloning/healing/retouching on top of ACR, they have to rely on what is in ACR. But if Thomas Knoll is primarily interested in PS he has no need to add anything to ACR.

Thomas is primarily interested in raw image processing (and the image quality of that processing) and Lightroom has benefited from that interest. No, he's not particularly interested in retouching or massive image manipulation, he's been there, done that. And Lightroom couldn't survive at all if it didn't leverage the Camera Raw processing pipeline. So, yes, Camera Raw and Lightroom are joined at the hip. I see no interest in anybody at Adobe severing that (as far as I know).

So, the line in the sand is gonna be (as you paraphrased it): "We are offering two programs that have slightly overlapping functionality but if you are dealing with many images and occasionally have to considerably edit a single image then you need both programs".

[TK2142]

Jeff Schewe wrote:

Substantial imaging involved with retouching, layers, compositing–the things that Photoshop is designed for–won't be put into Lightroom because it's not technically feasible with the parametric editing paradigm.

Your explanation is wrong. But I give up now.

Thanks for the discussion.

[DdeGannes]

Jeff also said "Could Lightroom force fit a pixel based editing module into Lightroom? Yes, I suppose but the interest in producing yet another pixel editing tool is simply not there."

Market conditions in the future might dictate otherwise, but I do not think Abobe will develop Lightroom to the stage where it would be an alternative to Photoshop CS.

[Lee_Jay-ZyZk56]

DdeGannes wrote:

Market conditions in the future might dictate otherwise, but I do not think Abobe will develop Lightroom to the stage where it would be an alternative to Photoshop CS.

It already is.

[DdeGannes]

Only to the extent that ACR/Bridge does in Photoshop.

[TK2142]

DdeGannes wrote:

Jeff also said "Could Lightroom force fit a pixel based editing module into Lightroom? Yes, I suppose but the interest in producing yet another pixel editing tool is simply not there."

Market conditions in the future might dictate otherwise, but I do not think Abobe will develop Lightroom to the stage where it would be an alternative to Photoshop CS.

FWIW, I don't want Lightroom to be turned into an alternative to PS. I don't have an interest (in Jeff's words) in yet another pixel editing tool either.

I'd like to be able to do manage many images and do some basic healing/cloning/retouching using a non-destructive approach without involving two applications. If that isn't a valid motivation then lens corrections and local adjustments should never have been added to LR either.

[DdeGannes]

I am sure you will see improvements to these areas in Lightroom, as I see it LR 3 was a new rebuild, new process engine, new noise reduction/ sharpening and introduction of Lens correction profiles.

The rush to meet the introduction of PS CS5 seams to have left them short on the testing of the upgrade and they are now struggling to deal with the performance bugs introduced with LR 3.x. JMHO. Raw conversion software is still in a rapid stage of development and other software providers keep pushing the envelop, Capture 1, DxO, Bibble, Aperture and others.

[areohbee]

It might be more accurate to say:

It would require extensive re-design of Lightroom.

We all know that lots of stuff is possible parametrically - look at Nx2, Aperture, and Bibble.

But they were designed differently, and their design has strengths and weaknesses, as does Lightrooms.

Dont get me wrong - I think at some point Adobe will have to redesign Lightroom in order to remain competitive, and incorporate more comprehensive editing features. But, they have less incentive than Nikon, Apple, or Bibble, since they have their *other* product that fills the gap.

PS - My apologies for continuing the off-topic discussion.

R