Luminous Landscape Forum
Raw & Post Processing, Printing => Adobe Lightroom Q&A => Topic started by: rdonson on July 08, 2016, 06:44:50 am
-
https://helpx.adobe.com/lightroom/kb/optimize-performance-lightroom.html
-
what i find curious they do not mention ssd drives
-
Thanks for posting. Finding information on the Adobe site is akin to search for a needle......?
-
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.
-
And perhaps - an SSD would speed up seeking and storing data, but it may not contribute that much to processing speed.
-
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.
-
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. :(
-
I don't know about these suggestions. The first one is
That's a problem these days. :(
Why?
-
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?
-
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
-
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.
-
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.
-
Google search also finds this more current Technote...
https://helpx.adobe.com/lightroom/kb/performance-hints.html
-
And this...
https://www.pugetsystems.com/labs/articles/Adobe-Lightroom-CC-6-Multi-Core-Performance-649/
-
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 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/
-
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
-
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.
-
Now I can't tell misinformation from real information which makes this thread seem pointless now.
Always a challenge. :)
-
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.
-
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.
You don't know any of the suggestions and assertions you stated above is a fact, John, just due to the fact that you just stated with this...
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.
So proof of any improvement in performance with LR optimization suggestion will depend on so many variables the user doesn't have a ground zero starting point in speed to reference.
What's a bog down with one system is a bump in speed to another.
Maybe the speed standard or line in the sand so to speak should be established with the speed and responsiveness seen in YouTube LR tutorial videos which appear much faster than some over others including my own system.
-
I think most of us know but perhaps under-appreciate, application developers make decisions about what generations of operating systems and core hardware their applications will support and they usually tell the community what that universe is; people working outside that universe need to upgrade or use something else. One cannot hold them accountable for speed because even within the supported universe, the permutations and combinations of hardware and software configurations among the user community are simply too large to make that practical. By striving to improve processing efficiency as John mentions, they are trying to assure that the application will work faster and more efficiently on more supported systems than before those improvements. I don't think they can be reasonably held to more than that. There are third party websites that benchmark speed tests for certain common functions of the more popular applications on a range of computing environments, so one can reference those for a view about where one's own system stands by comparison.
-
You don't know any of the suggestions and assertions you stated above is a fact, John, just due to the fact that you just stated with this...
So proof of any improvement in performance with LR optimization suggestion will depend on so many variables the user doesn't have a ground zero starting point in speed to reference.
What's a bog down with one system is a bump in speed to another.
Maybe the speed standard or line in the sand so to speak should be established with the speed and responsiveness seen in YouTube LR tutorial videos which appear much faster than some over others including my own system.
So, "Doubting Thomas", a.k.a. Tim, do whatever you want. Just stop asking for advice or suggestions. I don't need to waste my time typing for that type of response.
-
So, "Doubting Thomas", a.k.a. Tim, do whatever you want. Just stop asking for advice or suggestions. I don't need to waste my time typing for that type of response.
But I didn't ask you for any advice or suggestions, John. You volunteered information to my reply of my stating this thread has been a waste of time to be concerned about improving LR speed and responsiveness due to all the variables involved where no one can attest to how fast LR should be on any given system new or old. And we haven't even factored in possible bugs that still exist with some systems.
There's a few threads recently of users complaining about 30 second waits for edits to show up in the preview and other slow downs on far more powerful and current systems than mine.
So if a list of optimization tips is offered up by a myriad of unknown users with unknown systems it proves my point that this thread and others like it are a waste of time.
I never doubt. I get the facts and so far there hasn't been any verifiable facts stated in this thread.
-
But I didn't ask you for any advice or suggestions, John. You volunteered information to my reply of my stating this thread has been a waste of time to be concerned about improving LR speed and responsiveness due to all the variables involved where no one can attest to how fast LR should be on any given system new or old. And we haven't even factored in possible bugs that still exist with some systems.
There's a few threads recently of users complaining about 30 second waits for edits to show up in the preview and other slow downs on far more powerful and current systems than mine.
So if a list of optimization tips is offered up by a myriad of unknown users with unknown systems it proves my point that this thread and others like it are a waste of time.
I never doubt. I get the facts and so far there hasn't been any verifiable facts stated in this thread.
I guess some people just need to whine. As I remember, you use back level software and older hardware and then complain about everything.
You, personally, are looking for absolutes,....easy answers to difficult, complex questions...which do not exist.
Others may, more wisely, be interested in guidance on how they can move to improve their systems.
-
https://helpx.adobe.com/lightroom/kb/optimize-performance-lightroom.html
Running on an I7 with 32GB of RAM and SSD and 4K screen, I find the interface delays the most irritating. Both stutter and waiting for effects of control movements to be displayed. Even just waiting for a histogram to display when selecting a photograph. I have Automatic Write XMP data selected because I use Bridge/ACR regularly. ACR is much quicker, probably because it is not doing so much coordinating in the background.
-
Running on an I7 with 32GB of RAM and SSD and 4K screen, I find the interface delays the most irritating. Both stutter and waiting for effects of control movements to be displayed. Even just waiting for a histogram to display when selecting a photograph. I have Automatic Write XMP data selected because I use Bridge/ACR regularly. ACR is much quicker, probably because it is not doing so much coordinating in the background.
When the LR GPU support was announced, Eric Chan discussed the tradeoffs of using the support with large screens, such as 4K. A lot depends on factors such as data transfer to the GPU and it's speed. This can be particularly true on older or slower motherboard designs.
He said, there are times it may be faster not to use GPU processing. I would suggest you try with and without.
-
Running on an I7 with 32GB of RAM and SSD and 4K screen, I find the interface delays the most irritating. Both stutter and waiting for effects of control movements to be displayed. Even just waiting for a histogram to display when selecting a photograph. I have Automatic Write XMP data selected because I use Bridge/ACR regularly. ACR is much quicker, probably because it is not doing so much coordinating in the background.
I don't have the slow downs you have with both LR4/ACR 6.7 (CS5) on a 2010 Mac Mini OS 10.6.8/8GB RAM, but I've noticed intermittent interface delays across all of my open apps (Firefox, CS5 Bridge, Photoshop) possibly caused by background activity when I traced the delays to Firefox automatically updating which requires I restart Firefox for them to take affect only I never get a dialog box alert that this is happening.
I just suspected that something was going on in the background after noticing the green LED "Ethernet" light on my AT&T U-verse box was blinking wildly but I wasn't downloading anything through Firefox. I checked "About Firefox" dialog box and sure enough it indicated it had updated without my knowledge and that I needed to restart for the changes to take effect. After doing so and spending a bit of time working in my open apps the slow downs stopped.
You might look into all open apps including any Adobe CC and others that do a check in on your system by just disconnecting your internet connection on your computer, restarting and see if the slow downs continue. You might have to spend a while working in LR with the internet disconnect to give LR and OS time to rearrange the furniture so to speak with API's that rely on this internet connection.
And just to be clear this is just speculation based on observation. Not sure if it would work for your system, but it's not too intrusive or a PITA to implement.