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

[Sean McCormack]

Ah.. I hate when email responses do that.. it's rather annoying: Here's what I said:

Are you saying that a 1:1 build on previews will somehow build a cache file set of entries that would help performance even after the 1:1 files are gone?

Yes

If I do build 1:1 previews on top of the 1620 size ones, and then the 1:1 are deleted at the end of the day, am I without any preview size being available for Library?

Lightroom will always generate a preview if needed. I just created a test catalog. Imported one image with 1:1 selected. Opened the previews package to check, and there was 1 5.7MB file there. Discarded 1:1 (which initially appears to do nothing). Restarted Lightroom. I now have a 1.7 MB file (My preview setting is 2048 High). Clicking to zoom in, I see a 3.7MB file, and finally when I drag about the image, the preview file goes back to 5.7MB as per the original 1:1.

[thewhitedog]

What was that, Seán?

[Sean McCormack]

On email, so don't know what you're referring to?

[ChBr02]

ChBr02 wrote:

What I need to know is whether or not the Camera Raw Cache is of any use whatsoever when you are only editing jpg's?

No use whatsoever. You can easily verify this by looking into the cache directory. If you never deal with RAW files it will be empty and will stay that way.

=======================

Thanks.  Anyone care to weigh in on my other previous questions, plus one more????

2) What element (catalog, original photos, virtual memory, programs, etc.) would benefit the most from the fastest DASD available.  On one platform, I have no choice, but on the other, I could upgrade to SSD, use available 10K WD drive mirror, 1TB 7200rpm drives, etc.  I can always add an external eSATA 2 drive to either platform.

3) What would be the benefit to ugrading from 6GB to 8GB RAM running Windows 7 Ultimate?

4) My screen resolution is 1920 x 1080.  The only possible resolutions shown for preview are:

     a- 1024

     b- 1440

     c- 1680

     d- 2048

     Performance wise, which resolution should I pick?

Charlie (:-)>

[TK2142]

ChBr02 wrote:

4) My screen resolution is 1920 x 1080.  The only possible resolutions shown for preview are:

     a- 1024

     b- 1440

     c- 1680

     d- 2048

     Performance wise, which resolution should I pick?

It depends. If, in Library mode, you always have at least one panel either to the left or the the right open then you can choose c).

If, however, you sometimes make both left and right panels go away to see an image in full width (again that's in Library mode) then you'll have to chose d), otherwise LR has to compute the image on the fly which will cost time.

Obviously, option c) is preferable in terms of space consumption on your harddrive.

[Ian Lyons]

ChBr02 wrote:

4) My screen resolution is 1920 x 1080.  The only possible resolutions shown for preview are:

     a- 1024

     b- 1440

     c- 1680

     d- 2048

     Performance wise, which resolution should I pick?

Given your screen resolution, there is little point choosing anything less than 1680 and since 2048 is bigger than your screen resolution that is an equally pointless choice.

[ChBr02]

Thanks Ian & TK. Wonder why Lr doesn't support 1920? Most decent laptops support 1920 x 1080 which is the standard HDTV resolution.

[areohbee]

2048 waists pixels but its the only way to obviate re-rendering when viewing standard previews on a 1920 monitor sans panels, unless I still don't understand what I thought I understood...

I would think 1920 minus the size of the borders (which would be in the 1800s - i.e. more than 1680) would be perfect (for optimal performance) - ignoring issues of resizing algorithm efficiency... In any case, I think Adobe should re-program Lightroom to decide for us, so us poor users don't have to trouble ourselves... Maybe a single checkbox for optimize for storage vs. speed and hide the details... Or even radio buttons:

- No previews (for use on constrained laptops or temporary setups...)

- Optimize previews for storage (of the present choices, would choose 1680 on 1920 monitor).

- Optimize previews for performance (of present choices, would choose 2048 on 1920 monitor).

Rob

[Lee_Jay-ZyZk56]

areohbee wrote:

2048 waists pixels but its the only way to obviate re-rendering when viewing standard previews on a 1920 monitor sans panels, unless I still don't understand what I thought I understood...

I think LR can and will upres somewhat from an existing preview without a full higher-res rerending when the difference between the preview and the screen image is small enough (don't remember the number but 30% sticks in my head for some reason - it could easily be wrong but it's something modest like that).

[areohbee]

Lee Jay wrote:

I think...

You think? ;-}

If that's the case then 2048 would never be better performing than 1680 on a 1920 monitor. And its only advantage would be a theoretical and probably very neglibible quality advantage by replacing the slight upscaling with a slight downscaling.

R

[Lee_Jay-ZyZk56]

That's why I use 1680 myself.  2048 is supposedly acceptable for 2560 monitors.

[areohbee]

Lee: I started at 1440 (the default), learned some things and upped it to 1680, learned some more and upped it to 2048, and now with this new piece of info (auto-upscaling) - if you were a little more sure of yourself, I'd lower it back to 1680.

Tom Hoggarty: Are you sure your users are better qualified than your software engineers to set this value? - I'm not.

I mean I'm OK with it the way it is, provided I have all the information necessary to make the right decision, which I almost do now, but 99% of users are perplexed by this setting. I consider y'all (Adobe Lightroom engineers) to be masters of simplification. Maybe when you get all the other performance issues straightened out......

Rob

[areohbee]

JayS In CT wrote:

O.K., so then if we have large cache sizes, are we running some risk of added time to fetch the baseline image?  Would it be better to have a somewhat smaller cache (maybe not 1GB), but something that is refreshed more frequently with items currently being worked on vs. having a cache large enough to hold thousands of images, but takes longer to look up?

It won't take significantly longer to fetch an entry from a big cache than a small one.

As a rule of thumb, I'd say 1GB is too small on a modern system with a big drive. Lr2 had a 50GB limit, which Lr3 has relaxed. For me, its hard to imagine someone benefiting significantly from more than 50GB unless they are a real power-user-editor...

For most of us though, I'd think somewhere between 5 and 50 would be plenty.

[Sean McCormack]

not quite, if you fill the cache, it'll delete the oldest entries.

And that is literally as much as I know, bar that if your screen is larger than 2048, standard previews are too small and Lightroom needs to use the 1:1 previews. Soif you've a 30 inch screen @ 2500px wide, you'll always need 1:1's. Ian Lyons is the source of that nugget-I've only a 24" at 1900px wide.

[JayS_In_CT]

Seán McCormack wrote:

not quite, if you fill the cache, it'll delete the oldest entries.

And that is literally as much as I know, bar that if your screen is larger than 2048, standard previews are too small and Lightroom needs to use the 1:1 previews. Soif you've a 30 inch screen @ 2500px wide, you'll always need 1:1's. Ian Lyons is the source of that nugget-I've only a 24" at 1900px wide.

Same here Sean, a 24" Dell Ultrasharp at 1920..and I guess as far as things rolling out of the raw cache, I'm still confused.  If there not really used to store anything that is of use to Develop, than what purpose is served?

Jay S.

[TK2142]

JayS In CT wrote:

If there not really used to store anything that is of use to Develop, than what purpose is served?

The Develop module uses the Camera Raw Cache.

Rendering a RAW file is a multi-step process. The first few steps are always the same, independently of any subsequent edits to the image. These first steps are cached (or at least some data to speed up the first steps, because the files in the cache seem way too small to represent fully demosaiced versions of the original).

If you don't render 1:1 previews upon import then the Camera Raw Cache will not be pre-populated but this is not a terribly big deal as the cache entries will just be generated on the fly as soon as you start developing images. Only if you want to transfer the little time it will require to create the cache entries to the import phase, it makes sense to do this by requiring 1:1 previews. Note, however, that this implies that your Camera Raw Cache is rather huge. Otherwise most of the cache entries won't survive because they will be overwritten by later images during the import.

So, yes, the Develop module makes use of the Camera Raw Cache but the impact on performance is not a dramatic one. It most helpful to those with very large RAW files and few edits.

[JayS_In_CT]

TK2142 wrote:

JayS In CT wrote:

If there not really used to store anything that is of use to Develop, than what purpose is served?

The Develop module uses the Camera Raw Cache.

Rendering a RAW file is a multi-step process. The first few steps are always the same, independently of any subsequent edits to the image. These first steps are cached (or at least some data to speed up the first steps, because the files in the cache seem way too small to represent fully demosaiced versions of the original).

If you don't render 1:1 previews upon import then the Camera Raw Cache will not be pre-populated but this is not a terribly big deal as the cache entries will just be generated on the fly as soon as you start developing images. Only if you want to transfer the little time it will require to create the cache entries to the import phase, it makes sense to do this by requiring 1:1 previews. Note, however, that this implies that your Camera Raw Cache is rather huge. Otherwise most of the cache entries won't survive because they will be overwritten by later images during the import.

So, yes, the Develop module makes use of the Camera Raw Cache but the impact on performance is not a dramatic one. It most helpful to those with very large RAW files and few edits.

TK,

The that doesn't explain the large number of entries in the cache file all dated on the day I changed from 1440 to 1680 and recreated a standard size (not 1:1) rendering of all the files in my catalog.  I certainly didn't go back and edits them all.

Jay S.

[Sean McCormack]

I've not tested with smaller sizes, but I'd bet that because you had to go back and look at the files to generate new ones, that it also filled the cache for that reason.

[TK2142]

areohbee wrote:

TK: Please forgive if I've overly softened your points about the ACR cache while venturing to speak for you ;-}

Not a problem. Thanks for the support, Rob.

[TK2142]

Seán McCormack wrote:

TK, actually it does make a difference if you render 1:1 previews, because along with creating the Library Previews, it's also filling the Camera Raw Cache, so when you do go to Develop, you've cut the render time down. Yes, if you do a lot of edits, especially spotting, it's proportionally less, but responsiveness is a feel thing, and shaving a second off can help it feel faster. You may be working on 50 images, but I'm shooting a lot more than that, so yes, it does make a difference.

Thanks, Seán for that piece of information. I never said anything about 1:1 previews, but it is interesting to learn that chosing this size for importing implies the generation of Camera RAW Cache entries.

Regarding the speed up afforded by the Camera RAW Cache, it perhaps should also be noted that it will be the more noticeable, the higher the MP count of one's camera is. My camera has a modest resolution so saving the pre-rendering stage doesn't help much. For a Sony A900, 24MP file, the time savings are no doubt considerably larger.

Coming to think of the Library previews, I'm wondering whether LR takes the correct approach. These preview pyramids take up a *lot* of space. Wouldn't it be better if that space could be limited and then larger previews would be discarded when they haven't been accessed in a while and the space is needed for more recent images? Perhaps thumbnail size previews could be discarded last.

That feature would probably make most sense for people who cannot afford to dedicate unlimited amounts of their harddisk to LR usage and who use multiple catalogs. If I want to regain the space occupied by previews for catalogs that I haven't been using for a while then I have to do that manually. It would be more convenient if a limited preview space would be managed by LR. But I'm digressing, sorry.

[Sean McCormack]

I did a post a while back on moving the preview cache for that very reason (using symbolic linking).

A few people, including Seth Resnick, keep 1:1 previews forever, so they always have access when on the road, even if the physical images reside on a server at home. I mention this because it's the other end of the spectrum, showing Lightroom has to cover all bases.

You can of course set the 1:1 discard to be daily, so it can be automatic from that perspective, keeping the preview cache size down.

[areohbee]

dwterry wrote:

AHA!  I found the solution to my performance issues - The cache size was set to just 1.0 GB.

Anyway, I'm back to being a happy camper.  I get lightning fast switches between images in library mode again. 

You gonna come clean dw? (or just sweep this one under the rug...)

Put another way: ACR cache size should NOT have affected library mode switching performance, thus whatever fixed your problem, assuming you're not crazy, was due to something else - but WHAT???

_R

[dwterry]

Sorry Rob, I've been busy the last two days.  I processed 480 pictures last night and LR 3.3 was super fast the whole time.  Prior to my change to the cache it was running dog slow.

I'll try changing the the cache back down now to see if it makes a difference ... but I don't have another photo shoot until Saturday, so we'll see.

[dwterry]

Hehe... well, I can't explain the sudden increase in speed.  I changed the cache size back to 1.0 with no change.  Then I got curious and looked at the folder assigned to the cache and it was empty.  Well.  I guess that means it's not even used by Lightroom. 

Back to you regular programming....

[areohbee]

Once upon a time, my Lightroom was failing to use ACR cache. I relocated the cache and it began to be used again - clearly a bug that may still be in 3.3. As TK pointed out, the value of the ACR cache is somewhat marginal anyway, but its still faster when used...

Also, as I mentioned, it seems to me that sometimes Lightroom does not use previews when it should. It sounds like the same thing has happened to you. I have not trouble-shot it yet, so I'm not even certain about what I think I've noticed, but it sounds like there is a bug in this domain as well, and if you, me, and anyone else who has the problem and is so inclined, were to keep an eye on it, it might help Adobe weed it out...

Unlike ACR cache, proper use of previews is critical to loupe viewing performance.

_R