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

[Sharpis]

A good suggestion.

[dustybush]

My issues seem to be related to the Print module. When I launch LR into the Library module, it uses about 150 MB of RAM. Whenever I switch to the Print module (or launch LR into the Print module), the RAM usage jumps up to over 3 GB and my computer becomes virtually unusable. I never used the Print module before 3.3, so I can't say if it is a new issue or not, but that memory usage seems excessive. Strongly considering re-installing 3.2 at this point.

Running Windows 7 64-bit, FWIW.

[thewhitedog]

@ Rob: Glad to hear some Windows users are doing OK. Unfortunately, as far as I know Adobe doesn't release sales figures for the Mac and PC versions of their software so I couldn't even pretend to offer an educated guess which platform has more Photoshop and Lightroom users. Though we might assume that, given the Mac's proverbial popularity among graphics professionals, that the proportion of Macs running Adobe products is larger than its market share in general. In any case I think it's safe to say that each platform has its strengths and weaknesses. Since they use much of the same hardware now the differences between them have certainly diminished.

Back to the subject of performance, when Lightroom stalls out on me it's not because I have used an unusual number of adjustment brushes on a single image; it seems to be cumulative. When I'm running through a batch of pictures, applying the adjustment brush is one of the last operations I perform. So I will move from one image to the next brushing out imperfections. I will also use the gradient tool to balance uneven lighting, but this seems to cause fewer problems. Anyway, it's not unusual, after processing a number of images, for the adjustment brush to freeze up on me. I then quit and restart Lightroom and good performance returns. This is different than what other people are reporting, I think; they seem to have trouble when they apply a lot of brushes to the same image. Personally, if I find an image needs more than a dozen brushes, I prefer to do the work in Photoshop where the healing brush doesn't require a target.

[H_D_]

@thewhitedog

In my setup Lightroom freezes for a few seconds with every (and also the first) Spot removal adjustment (only jpg, RAW works fine).

Meaning I mark the spot, move the source circle around to find an appropiate source and voila the system freezes.

[thewhitedog]

@ H.D. : That bites. Like I say, I feel lucky. Clearly it could be worse. These problems with Lightroom 3 have been dragging on for months now. Here's hoping Adobe sorts things out sooner than later. I'm sure many people have already lost patience waiting for a fix. I wonder how far this news about performance problems with Lightroom 3 has spread beyond these forums?

[JayS_In_CT]

All,

So a new performance question around previews. I understand that there is some correlation between the Library Preview cache and Develop module in the Library provides the base level but I've also found a direct connection... meaning, if I render a 1:1 Preview (simply by going to 1:1 size) in the library module and then switch to develop, the load time (at 1:1) is instantaneous..  This includes heavily edited files previously not viewed as 1:1 in Library.  Am I wrong in the understanding that a 1:1 rendering in Library mode does not include all the edits and is, as I said, the base from which the Develop image is built on?  My "standard" size image which I build on import are 1680 on a 24" screen which is 1920.. I do have the viewing window in Library smaller given the side panels.  If I use 2048, which is still smaller than full size, would I gain more?

Jay S.

[Lee_Jay-ZyZk56]

JayS In CT wrote:

All,

So a new performance question around previews. I understand that there is some correlation between the Library Preview cache and Develop module in the Library provides the base level but I've also found a direct connection... meaning, if I render a 1:1 Preview (simply by going to 1:1 size) in the library module and then switch to develop, the load time (at 1:1) is instantaneous..

That's becuse rendering the 1:1 previews populated the Camera Raw cache.  If that cache isn't set large enough for the number of images you rendered, some images won't be in the cache when the rendering is done.

[JayS_In_CT]

Lee Jay wrote:

JayS In CT wrote:

All,

So a new performance question around previews. I understand that there is some correlation between the Library Preview cache and Develop module in the Library provides the base level but I've also found a direct connection... meaning, if I render a 1:1 Preview (simply by going to 1:1 size) in the library module and then switch to develop, the load time (at 1:1) is instantaneous..

That's becuse rendering the 1:1 previews populated the Camera Raw cache.  If that cache isn't set large enough for the number of images you rendered, some images won't be in the cache when the rendering is done.

Lee Jay,

So then I'm back to the question that keeps going round and round (and my ACR cache is 60GB) about the 2 different cache's.. I rendered the 1:1 in the Preview cache, not the ACR cache, yet Develop access is now instant with no load time (practically none)..  Shouldn't the 1:1 in Library be stored in the Previews cache file in some location as the catalog files?  Wish I had a flowchart diagram with a "If this ...  than that ..  but if you branch this way, than that occurs"  🙂   Again I thought that the Preview cache only provided the basis for a Develop module image.. note I said heavily edited.

Jay S.

[DdeGannes]

The Previews are used by the Library Module the Develop Module uses the Camera Raw cache.

[JayS_In_CT]

DdeGannes wrote:

The Previews are used by the Library Module the Develop Module uses the Camera Raw cache.

Thanks, and I understand that.  The question I have is why a 1:1 update in Library mode makes the load in Develop instantaneous (at 1:1) for all intents and purposes.  Again I'm talking about a heavily edited 1:1 image.  My understanding of the the relationship between Preview and ACR cache is that the Preview does not reflect the changes made in Develop (that's been proven but looking at the preview cache as changes are made in Develop).  I understood that the image in the Preview cache was basically the "starting point" for images being displayed in Develop. If I understand it correctly an image that has perhaps fallen out of the ACR cache, would retrieve the Preview cache image apply any image adjustments made in Develop before displaying it (accounting for some of the load time).

Again, what I'm not sure of is why viewing an image in Library at 1:1 results in the much much quicker load of a heavily edited image (at 1:1) in develop?  Going by what you're saying (which I think is partially true given the Develop does draw on the Preview cache) there would be no reason for viewing something at 1:1 in Library impact 1:1 in Develop, yet that's not what I'm seeing.

Jay S.

[ChBr02]

>>"The Previews are used by the Library Module the Develop Module uses the Camera Raw cache."<<

Does the Develop Module use Camera Raw Cache for jpegs?

BTW, is there a forum about the ungodly slow adobe forum website?

[Lee_Jay-ZyZk56]

JayS In CT wrote:

So then I'm back to the question that keeps going round and round (and my ACR cache is 60GB) about the 2 different cache's.. I rendered the 1:1 in the Preview cache, not the ACR cache, ...

Don't forget that Lightroom's rendering engine is Adobe Camera Raw (the code - not the Photoshop plugin).  That means, when you render images, for whatever reason, the Camera Raw code is called, and therefore its cache gets populated.  That's true even if the purpose was to put a JPEG into the preview cache, an image on your screen in loupe view, or an image on your hard drive as an export.

[JayS_In_CT]

Lee Jay wrote:

JayS In CT wrote:

So then I'm back to the question that keeps going round and round (and my ACR cache is 60GB) about the 2 different cache's.. I rendered the 1:1 in the Preview cache, not the ACR cache, ...

Don't forget that Lightroom's rendering engine is Adobe Camera Raw (the code - not the Photoshop plugin).  That means, when you render images, for whatever reason, the Camera Raw code is called, and therefore its cache gets populated.  That's true even if the purpose was to put a JPEG into the preview cache, an image on your screen in loupe view, or an image on your hard drive as an export.

Lee Jay,

I'm not sure that's 100% correct.  That would imply when you render several hundred imports in Library mode with a standard preview that Camera Raw is called each time?  That also flies in the face a bit of what's been said about the Preview cache not getting populated or updated with changes made in Develop (meaning the actual Previews that were created during import).  That would also seem to imply that if I wanted to work on 50 images let's say, that if I did 1:1 previews on those 50, that they're now going to be almost instantly available at 1:1 in develop (which is what I saw but not what I believed was the processing inside LR).

Jay S.

[Lee_Jay-ZyZk56]

JayS In CT wrote:

Lee Jay,

I'm not sure that's 100% correct.  That would imply when you render several hundred imports in Library mode with a standard preview that Camera Raw is called each time?  That also flies in the face a bit of what's been said about the Preview cache not getting populated or updated with changes made in Develop (meaning the actual Previews that were created during import).  That would also seem to imply that if I wanted to work on 50 images let's say, that if I did 1:1 previews on those 50, that they're now going to be almost instantly available at 1:1 in develop (which is what I saw but not what I believed was the processing inside LR).

Jay S.

Camera Raw is certainly called to do renders.  The cache does populate whenever those renders are from raw image data.  This does not mean that the Preview cache (JPEGs for Library) gets populated whenever a render happens in Develop (though, it should at least sometimes, in my opinion), but it does mean the opposite.

[Ian Lyons]

JayS In CT wrote:

All,

So a new performance question around previews. I understand that there is some correlation between the Library Preview cache and Develop module in the Library provides the base level but I've also found a direct connection... meaning, if I render a 1:1 Preview (simply by going to 1:1 size) in the library module and then switch to develop, the load time (at 1:1) is instantaneous..  This includes heavily edited files previously not viewed as 1:1 in Library. 

It's only when the "Loading" bezel message disappears that your image is fully rendered. That's not the same as the sliders becoming available, which is a misunderstanding that way too many users have. Also, the time the "Loading" bezel stays on screen is, to all intents and purposes, a function of the CPU performance, not the availability of the previews or Camera raw cache file, and there are no currently available CPU that will render a file even close to instantly. Therefore, you might what to check whether you have inadvertently switched off the "Loading" bezel in Develop module View Options.

[JayS_In_CT]

Ian Lyons wrote:

JayS In CT wrote:

All,

So a new performance question around previews. I understand that there is some correlation between the Library Preview cache and Develop module in the Library provides the base level but I've also found a direct connection... meaning, if I render a 1:1 Preview (simply by going to 1:1 size) in the library module and then switch to develop, the load time (at 1:1) is instantaneous..  This includes heavily edited files previously not viewed as 1:1 in Library. 

It's only when the "Loading" bezel message disappears that your image is fully rendered. That's not the same as the sliders becoming available, which is a misunderstanding that way too many users have. Also, the time the "Loading" bezel stays on screen is, to all intents and purposes, a function of the CPU performance, not the availability of the previews or Camera raw cache file, and there are no currently available CPU that will render a file even close to instantly. Therefore, you might what to check whether you have inadvertently switched off the "Loading" bezel in Develop module View Options.

Ian,

The loading bezel is turned on.. I've been on LR since V1.  The loading message comes up for a brief 1/4 of a second or so, and this is the same machine that I've been using all along...  This happened after going into Library, rendering a 1:1 image then switching back to develop.  Normally I would expect to see the standard loading times I see with 7D files (longer with heavily edited ones).  I'm just reporting what I'm seeing.

Jay S.

[Vlican]

lightroom is still slow at browsing files... even after creating several GBs of thumbnails and previews, lightroom is still damn slow and that is unacceptable... this has not improved since LR1.3... ACDSee blows lightroom out of the water in this aspect

i cannot open lightroom and expect to flick through my images without the thumbnails lagging behind (while i can easily do that in other photo managers such as ACDsee pro)

lenovo sl400

core2duo t9400

4gb ram

LR is managing 28023 photos

[dwterry]

Yup, that's why I still use ACDSee to manage photos.  LR is just a raw processor for me, ACDSee is my image manager.

[areohbee]

Windows vs Mac performance.

This is techy, but may be pertinent:

A simple Lightroom task yield on Windows is over a 100 times slower on Windows than Mac.

Thus any operations in Lightroom that loop a bunch and have a yield or sleep in them will be extremely slow on a Windows machine.

This is as seen from the point of view of a plugin, but I'm guessing the plugin function for a task yield is just a thin wrapper around the same function used in Lightroom proper - but I dont know...

Rob

[ChBr02]

Rob,

When you say That you are seeing this "from the point of view of a plugin", do you mean running Winows as a task on a Mac?

Charlie

[areohbee]

I meant the LrTasks.yield function that plugins call to yield a plugin thread - takes 100+ times longer on Windows than Mac

i.e. when plugins yield, it takes 100+ times longer on Windows than Mac. Same may be true when Lightroom threads within Lightroom itself yield (independent of plugins...).

[ChBr02]

Rob,

Thanks. Your former comments make more sense to me now. I haven't had any relevant Mac experience since late 2005. Great graphics design platform, but a lousy corporate network citizen. The 1st computer I programmed had vacuum tubes.

Charlie

[areohbee]

I would guess the LrTasks.yield plugin function looks like this in the Lightroom source code:

1. so some stuff maybe.

2. call same 'C' function Lightroom itself calls to yield.

3. do some other stuff maybe.

I dont know what other stuff may be done for a plugin to yield, or even if it uses the same 'C' function as Lightroom (that part is conjecture/speculation). What I do know is its extremely inefficient on Windows..., and may be due to "step 2"... not sure what the implicactions are, but just thought it might be pertinent...

PS - I started with card punchers...

Over-'n-out,

Rob

[DJ-G]

I started with relays & plugboards, an IBM 403 (406?) calculating punch - a bit different experience from my homebuilt overclocked 6-core i7 980X . Back then I had a homebuilt Minivac . Speaking of the six-core, I tried the suggestion of disabling hyperthreading, but didn't see much difference.

DJ

[hhansard]

I believe extrapolating timing for a single lua call may provide misleading results when trying to explain performance of the entire LR code base on Mac-v-Win.  I would doubt 1) that the function is called repeatedly in a tight loop (now that would be bad) and 2) there may be some functions in the lua implementation that execute on windows more quickly than a mac. On a personal note, when I was a techie, I preferred compiled/linked code to interpretative because the runtime bugs on an interpretative code base were always much harder to catch (environmental) ---  I bet if you ask the folks supporting 3.x, some of that sentiment may ring home...