Adobe recommendations for LR performance

[rdonson]

https://helpx.adobe.com/lightroom/kb/optimize-performance-lightroom.html

[shotupdave]

what i find curious they do not mention ssd drives

[stamper]

Thanks for posting. Finding information on the Adobe site is akin to search for a needle......?

[Mark D Segal]

what i find curious they do not mention ssd drives

Useful article, but quite sloppily, it is undated. Reading through one gets the impression it dates back to Lightroom 3 and 4. At that time there would have been few people using SSD as their system drive. Even now it is probably a minority percentage of computer users, but growing.

[Mark D Segal]

And perhaps - an SSD would speed up seeking and storing data, but it may not contribute that much to processing speed.

[jrsforums]

And perhaps - an SSD would speed up seeking and storing data, but it may not contribute that much to processing speed.

That is a pretty old article.

I use SSD drives for both LR catalog and Raw Cache. 

The catalog is, as you say, aided in seeking and storage of development changes to image.

The cache speed is important to loading previews of develop adjustments.  That is, unless you are using DNG, where these are stored in the RAW image data.  Of course, until SSD prices come down, image files would probably be too expensive for SSD.

[Rory]

I don't know about these suggestions.  The first one is

Update to the most recent version of Lightroom

That's a problem these days.   

[jrsforums]

I don't know about these suggestions.  The first one is

That's a problem these days.   

Why?

[Tim Lookingbill]

Thanks for posting. Finding information on the Adobe site is akin to search for a needle......?

Agreed especially now that they keep redesigning their website and allowing dead links to load without their original source or the new locations. I had bookmarked LR4 "Help" back in 2013 and now when I load it I get the original link but...

http://help.adobe.com/en_US/lightroom/using/WS638E3AC9-A04C-4445-A0D3-F7D8BA5CDE37.html#WSFA6EBA44-BE96-4ac2-A72C-E7FB68D8FF11

Clicking backward in that page's source hierarchy listed at the top and bottom doesn't take you to where you want to go.

Aside from that can anyone confirm what it says about slow downs using "1:1" previews? I had no idea if you choose this that LR automatically generates all Standard, embedded and minimal previews. Read it carefully. It's more complicated than I remember reading it back in 2013.

Also does the part about the preview cache and Catalog needing to be kept in the same folder still apply for faster performance?

[jrsforums]

Agreed especially now that they keep redesigning their website and allowing dead links to load without their original source or the new locations. I had bookmarked LR4 "Help" back in 2013 and now when I load it I get the original link but...

http://help.adobe.com/en_US/lightroom/using/WS638E3AC9-A04C-4445-A0D3-F7D8BA5CDE37.html#WSFA6EBA44-BE96-4ac2-A72C-E7FB68D8FF11

Clicking backward in that page's source hierarchy listed at the top and bottom doesn't take you to where you want to go.

Aside from that can anyone confirm what it says about slow downs using "1:1" previews? I had no idea if you choose this that LR automatically generates all Standard, embedded and minimal previews. Read it carefully. It's more complicated than I remember reading it back in 2013.

Whenever you zoom in or need larger preview, you will need a 1:1 image.  This takes time, which is why they recommend that currently used images have 1:1 previews...this takes time.  That is why they recommend generating them ahead of time.  I generate them when importing.  The amount and space of 1:1 previews can be managed in previews.  Current LR allows standard previews to match the size of your screen, which is best practices as it avoids using, and loading, 1:1 images unless needed.

Also does the part about the preview cache and Catalog needing to be kept in the same folder still apply for faster performance?

Cache and catalog are always. Kept together.  If separated, a new cache will be created.

John

[rdonson]

Useful article, but quite sloppily, it is undated. Reading through one gets the impression it dates back to Lightroom 3 and 4. At that time there would have been few people using SSD as their system drive. Even now it is probably a minority percentage of computer users, but growing.

The article may date back to Lr 4 (2012) as it references Thunderbolt (2011) and USB 3 (2008).  Still most of the info itself is still useful other than lack of acknowledgement of SSDs. 

[Mark D Segal]

The article may date back to Lr 4 (2012) as it references Thunderbolt (2011) and USB 3 (2008).  Still most of the info itself is still useful other than lack of acknowledgement of SSDs.

Yes, I think so too.

[jrsforums]

Google search also finds this more current Technote...

https://helpx.adobe.com/lightroom/kb/performance-hints.html

[jrsforums]

And this...

https://www.pugetsystems.com/labs/articles/Adobe-Lightroom-CC-6-Multi-Core-Performance-649/

[Tim Lookingbill]

From jrsforums first link under...Spot Removal tool, local corrections, and History panel

If you've been creating many local or spot corrections, your history could be long, which can slow Lightroom's performance as a whole.

Clear the History panel by clicking the X on the right of the History panel header.

I had no idea the length of the history state can slow performance. An added bonus that I delete it anyway after final edit.

Thanks for posting the link, John.

[paulbk]

I have the dual processor problem as explained in link below. Lightroom simply does not work well with 2 CPUs. Sometimes so slow > un-usable.
I have no problem with Photoshop CC on same system. Works well.

https://www.pugetsystems.com/labs/articles/Adobe-Lightroom-CC-6-Multi-Core-Performance-649/

[fdisilvestro]

From jrsforums first link under...Spot Removal tool, local corrections, and History panel


    If you've been creating many local or spot corrections, your history could be long, which can slow Lightroom's performance as a whole.

    Clear the History panel by clicking the X on the right of the History panel header.


I had no idea the length of the history state can slow performance. An added bonus that I delete it anyway after final edit.

Thanks for posting the link, John.

I don't think this is true. It does not make any sense unless LR were really badly coded. The current settings are in a table different than the history (inside the catalog) and also it really does not matter in which order you applied the edits. Moreover, the heading of that article says the following:

   

This TechNote is a list of less-traditional suggestions to performance issues that customers have described on social media sites.

So, it is up to you to assign credibility to those suggestions

[Tim Lookingbill]

Thanks for that catch, Frank. I missed it jumping ahead through the list.

So these links to LR optimization pages has always been a list of suggestions based on user trial and error which explains why when I applied them in the past it didn't make any difference in LR responsiveness and speed.

Now I can't tell misinformation from real information which makes this thread seem pointless now.

[Rory]

Now I can't tell misinformation from real information which makes this thread seem pointless now.

Always a challenge.   

[jrsforums]

Thanks for that catch, Frank. I missed it jumping ahead through the list.

So these links to LR optimization pages has always been a list of suggestions based on user trial and error which explains why when I applied them in the past it didn't make any difference in LR responsiveness and speed.

Now I can't tell misinformation from real information which makes this thread seem pointless now.

Tim, LR optimization has to be looked at, not as a whole, but component parts.

Browsing images is going to be mainly I/O dependent.  SSD or fast drives, with fastest connection (USB3, SATA, bus channel) all influence.  Proper previews, Raw Cache or DNG.  The faster access the better.

Develop module adds additional factors.  To display the preview all the develop settings need to be redrawn.  There are lots of tradeoffs here.  Basics strings are one think, but lots of adjustment brush settings can, on a slower system, really bog a system town....often bringing it to a halt if overdone.  Then you have the trade off of GPU vs CPU and their relative speed, number of display pixels, transfer speed to the GPU, etc.

My suggestions:

Always use latest level of code.  Believe it or not, the LR guys are trying their best to squeak the best performance out, which is not easy with millions of differently configured/aged systems out there.  If my memory is correct, later versions have added prefetch to aid browsing. And remember, NO code is bug free....it can't be done, no matter how much you test, your test bucket cannot be as big as the systems and users out there.

The faster you can make the I/O, the happier you will be.  You need to manage cost/benefits, but SSD on the catalog and Raw Cache will give most improvement.  If you put images on external drive, you will slow up access.

Newer systems are faster.  Not just chip....memory speed, bus speed, GPU, etc.  Windows 7 may work great, but Windows 10 is faster.

Keep your system "clean".  Thinks build up over time...apps that we forget get loaded, invasive, but not malicious malware.  Sometimes reloading will give you, performance wise, a new system.

There are others, I am sure.  The subject is not simplex.  Best. Of luck working your way through.