30 Seconds to move between images in Develop

[WS007]

I have a problem with LRc on my Macbook Pro M1 (32 GB RAM/ 2 TB SSD): everything is running extremely slow. Changing from one photo to another takes e.g. about 30' in the "Development" module. The slowness applies to almost everything. It was not there from the beginning, but gradually increased within the last few months...

The Adobe support is underground: first one has to talk to a robot until the robot decides to give over to a human. The humans are little better, as they give general place paste/copy suggestions and refer to websides that are acessible anyhow, but all these suggestions do not help. Needless to say they fade away shortkly afterwards... . No advertisement for the expensive subscription 😞

I read here in the forum that the slowing down of LRc seems to be a common problem with Mac OS, but could not find a real solution. I wonder whether someone has found the problem and how to fix it. Below the system info...

Wolfgang

Lightroom Classic version: 13.4 [ 202406181129-60d181b7 ]
License: Creative Cloud
Language setting: en-AT
Operating system: Mac OS 14
Version: 14.5.0 [23F79]
Application architecture: arm64
Logical processor count: 10
Processor speed: NA
SqLite Version: 3.36.0
Power Source: Plugged In, 100%
Built-in memory: 32.768,0 MB
Dedicated GPU memory used by Lightroom: 7.724,0MB / 21.845,3MB (35%)
Real memory available to Lightroom: 32.768,0 MB
Real memory used by Lightroom: 4.274,7 MB (13,0%)
Virtual memory used by Lightroom: 417.249,2 MB
Memory cache size: 165,8MB
Internal Camera Raw version: 16.4 [ 1897 ]
Maximum thread count used by Camera Raw: 5
Camera Raw SIMD optimization: SSE2
Camera Raw virtual memory: 1385MB / 16383MB (8%)
Camera Raw real memory: 1432MB / 32768MB (4%)

Cache1:
Final1- RAM:963,0MB, VRAM:5.702,0MB, DSC05714.ARW
Final2- RAM:469,0MB, VRAM:0,0MB, DSC05715.ARW
NT- RAM:1.432,0MB, VRAM:5.702,0MB, Combined:7.134,0MB

Cache2:
m:165,8MB, n:1.159,1MB

U-main: 83,0MB

Standard Preview Size: 2048 pixels
Displays: 1) 3024x1964, 2) 3840x2160

Graphics Processor Info:
Metal: Apple M1 Pro
Init State: GPU for Export supported by default
User Preference: Auto

Application folder: /Applications/Adobe Lightroom Classic
Library Path: /Users/ws/Pictures/Lightroom/Lightroom Catalog-v13-3.lrcat
Settings Folder: /Users/ws/Library/Application Support/Adobe/Lightroom

Installed Plugins:
1) AdobeStock
2) Aperture/iPhoto Importer Plug-in
3) Flickr
4) Loupedeck2
5) Nikon Tether Plugin

Config.lua flags:

[dj_paige]

Try temporarily turning off your anti-virus.

[JohanElzenga]

Another thing to look at is Loupedeck. I believe there are some issues that have not been resolved yet.

[Lumigraphics]

Where are your photos located? Internal, external, network?

[WS007]

Hi Lumigraphics,

My photos are located on the SSD drive of the Macbook Pro...

[Conrad C]

That is definitely not expected; I use a similarly configured M1 Pro and don’t see anything close to that kind of delay moving between images in Develop. I get less than one second from image to image, maybe slightly longer if not already cached.

If it’s taking 30 seconds per image, open Activity Monitor and see if, during that 30 seconds, any process is using an unusually high percentage of CPU or GPU. If there is, it will either be Lightroom Classic (which would indicate a problem there), or it will be another process that is taking CPU away from Lightroom Classic (such as anti-malware software, accessory driver software, or another background process that might not be working properly).

Also, how much free space is on the Mac’s internal SSD? For any images that have been viewed recently in Develop, those should be cached for fast display in the Camera Raw cache, so another possible cause is something wrong along the path to the Camera Raw cache folder, such as a problem with folder permissions or corruption. The current location of and size limit for the Camera Raw cache is in Lightroom Classic > Preferences, Performance tab.

You have two 4K displays connected and there’s nothing wrong with that, but if the Secondary Display window is open, see if it’s any faster with the Secondary Display closed because that feature is said to be a factor in some slowdowns. I leave Secondary Display open all the time, but maybe I don’t notice a problem because it’s on a smaller display.

Another thing to try, if you haven’t done this lately, is to choose File > Optimize Catalog.

[Lumigraphics]

I'm not seeing delays either and I have a much lower-specc'd Mi Mac mini, with 4K and 2.5k displays attached. All my images are on external spinning hard drives and there is only a little lag if previews aren't built for a particular folder. I have almost 400,000 images in my catalog across four hard drives.

[Ian Lyons]

@Conrad C 

Add storing files on cloud storage such as OneDrive, iCloud, Dropbox, etc as possible reasons for the delay in loading images, especially if the images contain AI based masks, a large number of brush strokes, and Generative AI Remove.

It's also important to note that the secondary display does not use the GPU. So, there will be lag between the main screen and the secondary screen . The lag will be greater on systems with more powerful GPUs and the CPU can't feed the seondary display as quick as the GPU.

[Lumigraphics]

I'm not sure how much that applies to Apple Silicon since the entire image pipeline is different than traditional Intel PCs.

[Conrad C]

From what I have heard, I think what Ian said also applies to Macs, whether Intel or Apple Silicon.

Synced cloud storage can be a problem, especially if someone has enabled the option that several cloud storage services now offer (including Apple iCloud Drive) to save local space by keeping originals in the cloud only. That can cause files appear to be missing locally if what is local is a “dataless” placeholder file to the original on the cloud, and also because of load times over the Internet.

And I am under the impression that, Mac or PC, the only view that uses GPU acceleration is Develop, at least in Lightroom Classic 13.4. So if you have the same image in Develop in the application window and also in Loupe view in the Secondary Display window, the image in Develop is GPU-accelerated and the Secondary Display is not.

[Ian Lyons]

@Lumigraphics 

It doesn't matter whether it's a Mac with Intel or Apple Silicon, the secondary display does not use GPU acceleration. If anything, Apple silicon has resulted in the secondary display lag being more obvious than on Intel based Macs.

It's also worth noting that Full Screen mode doesn't use GPU acceleration either. This applies whether you use Windows or macOS, Intel or Apple Silicon.

[Lumigraphics]

Interesting, I assume Lightroom uses Metal and that is GPU-accelerated automatically, there is no way for a developer to avoid it. Some specific functions might use the CPU but I don't believe there is a choice for window compositing and such. Unless Adobe isn't using Apple frameworks and everything is custom code?

And yes I've read the graphics FAQ, its still not clear.

https://helpx.adobe.com/lightroom-cc/kb/lightroom-gpu-faq.html

[Conrad C]

Interesting, I assume Lightroom uses Metal and that is GPU-accelerated automatically, there is no way for a developer to avoid it.

By @Lumigraphics

That statement assumes that macOS decides what to GPU-accelerate, but that is not how it works. A developer decides what to GPU-accelerate and sends those operations to Metal, which then decides how best to accelerate on the available hardware, which Lightroom Classic doesn’t have to know about.

In the Lightroom Classic Performance preferences, if you deselect any of the “Use GPU…” settings, that causes the software to not send those routines to Metal, so they will not be GPU-accelerated (they’ll burden the CPU instead). If you let it use the GPU, it goes to Metal.

And yes I've read the graphics FAQ, its still not clear.

https://helpx.adobe.com/lightroom-cc/kb/lightroom-gpu-faq.html

By @Lumigraphics

I think we’re meant to go by the GPU system requirements for Macs in that link, which require a “GPU with Metal support.” If Metal wasn’t used in an essential way, it wouldn’t be required…

[Lumigraphics]

What I meant was if a developer writes software with standard API calls for things like CoreImage, Apple has already done the work.

Anyway, this is outside the scope of this question. But for some light reading:

https://developer.apple.com/documentation/metal/

[WS007]

Hi Conrad,

Thank you for th eextensive reply with a lot of suggestions that I will follow...

Just one thing: you say I have two 4k displays open? Not that I know: I have the retina display of the Macbook (1512x982) and one secondary monitor (BenQ SW270C with 1920x1080)...

Could this be the problem and how can I turn these two 4k monitors OFF (I cannot see them in systems settings)?

[Conrad C]

I am not sure if it’s the problem, I was only saying that one way to try and narrow down the problem by troubleshooting is to see if it’s any faster if one of the displays is disconnected.

That’s the short answer. The background is more complicated and gets nerdy so just keep that in mind if you decide to keep reading this…

What I noticed in your posted System Info was this line:

Displays: 1) 3024x1964, 2) 3840x2160

Display 1 is probably your MacBook Pro display, because the 14" MacBook Pro display is 3024 x 1964 hardware pixels. If you are reporting 1512 x 982, that’s the UI resolution setting (the resolution macOS Display settings calls “looks like”) at a Retina/HiDPI pixel density of 2x. Because 3024 x 1964 equals 1512 x 982 doubled along both dimensions.

Display 2 should be your BenQ SW270C, but I’m a little confused about System Info reporting it as 3840 x 2160 because that’s a 4K resolution and the BenQ website lists the SW270C as a 2560 x 1440 pixel display, which is normally not possible to set to 3840 x 2160 in macOS.

The only way I know of for all of the three numbers to be simultaneously true…

2560 x 1440 as listed in its specs on the BenQ website,

1920 x 1080 as reported by you, and 

3840 x 2160 as reported by System Info…

…is if the display panel has 2560 x 1440 hardware pixels, but it’s set to a UI resolution of 1920 x 1080 at a 2x UI scaling factor, which requires a 3840 x 2160 pixel buffer.  macOS might not let you set it up exactly that way, but I am wondering if maybe it got set up that way in the BenQ settings, or using other software?

The way I know this is that I also have a 2560 x 1440 display, and I can make the same set of different simultaneous numbers happen in both Lightroom Classic and macOS System Info, using BetterDisplay utility software. I can tell BetterDisplay to render a virtual 4K display to the 2560 x 1440 display, so that macOS reports as 1920 x 1080 Retina (2x pixel density), and Lightroom Classic reports it at 3840 x 2160.

[WS007]

This is interesting: I came to 1920x1080 as this is listed as "default" in the system settings. Therefore I have set it to this value. Now I have set it to 2560x1440. I will work for a while and in case this was the problem, I will report it...

[Conrad C · Accepted solution]

This is interesting: I came to 1920x1080 as this is listed as "default" in the system settings. Therefore I have set it to this value. Now I have set it to 2560x1440. I will work for a while and in case this was the problem, I will report it...

By @WS007

If you set it to 2560 x 1440, then you now have it set up exactly the same way I do for my 14" MacBook Pro and 2560 x 1440 display, so that should (?) rule out your display setup as a cause for long slowdowns because I run it the same way and it’s fast. So, something else is probably the cause…

[WS007]

I have set the resolution of the secondary BenQ display now to 2560x1440 (I do not knoiw why the MacOS suggests 1920x1080 by default?). After working for several days with LRc now, I can say that this solved the problem... 🙂

[JohanElzenga]

Good to hear that your problem is solved, but I find it very hard to believe that the display setting really was the cause. I often switch these settings on my 4K monitor, for example to 1920 x 1080 when I want to record a screen video for education purposes. I just did a quick test (even though I knew the answer) and I do not see any difference in speed of Lightroom Classic if I switch my display from one setting to another (including to 1920 x 1080 pixels).

[Lumigraphics]

I recently swapped my Mac mini second display from a 1920x1280 25" HP to a 2560x1600 30" Dell (main display is a 24" 4K LG) and have seen no difference in performance with any combination.

[JohanElzenga]

Yeah. If there was any difference at all, then you would expect it to be the exact opposite. A 1920 x 1080 setting would be faster than a 2560 x 1600 setting, because the GPU has to render fewer pixels to send to the screen. I think something else changed, and the change in display resolution is just a coincidence.

[Lumigraphics]

Yes in my case, the LG is scaled but the other two displays were both using native resolution.

[Conrad C]

Yeah. If there was any difference at all, then you would expect it to be the exact opposite. A 1920 x 1080 setting would be faster than a 2560 x 1600 setting, because the GPU has to render fewer pixels to send to the screen. I think something else changed, and the change in display resolution is just a coincidence.

By @JohanElzenga

Yes, I agree that something else was probably the real cause, but the “kind” of 1920 x 1080 this is does have the potential to slow things down. Because above, it was reported by macOS as 3840 x 2160, which means it was really running as 1920 x 1080 at 2x Retina pixel density.

1920 x 1080 = 2 megapixels of screen area to update

3840 x 2160 = 8.3 megapixels of screen area to update

So at 3840 x 2160, four times the number of pixels have to be calculated to update the screen.

However, the M1 Pro MacBook Pros should be able to handle multiple 4K displays smoothly, which is why I still think something else might have been the cause or contributing to it. But if Lightroom Classic Secondary Display is on the second monitor, maybe a factor in the bottleneck is not the Mac, but Lightroom Classic not rendering that many pixels fast enough if, for example, it is not able to use the GPU on the secondary display.

[JohanElzenga]

1920 x 1080 = 2 megapixels of screen area to update

3840 x 2160 = 8.3 megapixels of screen area to update

So at 3840 x 2160, four times the number of pixels have to be calculated to update the screen.

True, but the same applies for any other resolution setting lower than the native resolution, so there is no speed disadvantage of using 1920x1080 pixels. What MacOS does when you set a 4K display to 2560x1600 pixels is tell the apps that this display is 5120x3200 pixels, so it can downscale this to the native resolution of the display rather than having to upscale the 2560x1600 pixels to 3840x2160 pixels and get a soft image as a result.