Performance issue in Develop with 8.4 (8.4.1)

Thanks for the replies.  I'm surprised nobody else is reporting this, which always makes me wonder if it's some strange configuration I have.

So, looks like every OS issue has been taken care of,  GPU taken care of, Drive management in excellent order. Fir the number of images, Camera RAW CACHE Ok.

Is there some method of determining when the cache is insufficient?  I’m inferring from your statement that for some other number of images, 25GB WOULDN’T be enough cache?

If the problems were just in Library module, or at least not in Develop module, you might want to delete the library previews then recreate them.  Just 250 images, not a huge time waster.

Been there, done that.  Didn’t do much.  I’m currently working on yesterday’s images, so the short-term catalog has been recreated with 2012, 30 mb image files.  Import with the same basic adjustments as always.  1:1 previews created AFTER import completed.

One thing I was extremely poor at conveying. Is weighting the xmp metadata file. This was in reference to automatically righting the changes to xmp files. Those seperate xmp files. Only 250 photos however, so can not see why that would slow things down so much.

I never allow information to be written to the sidecar files if that’s the concern.  That’s done after culling and before renaming and converting to dng. 

I’ve got two scenarios:

WITH THE GRAPHICS PROCESSOR OFF

I went into the library and started marking images for deletion.  In loupe view, quick look, if bad label red, then right arrow.  If not bad, just hit right arrow.  Performs pretty well.

Switch to 1:1 view and go through same process.  Other than sometimes having to move the visible area to show the eye, it’s ABOUT the same speed.  Still acceptable.  As long as I DON’T modify anything on any image in Develop.

BTW:  If I have the metadata panel open in Library when doing this, it slows things HUGELY.  If I’m trying to move as quickly as possible I close ALL the palettes on both side panels.  Even when open everything is in Solo mode but having the metadata open is bad.

Now do the same thing in Develop.  Don’t CHANGE anything, just switch to develop mode.  In loupe, moving from image to image is SLOWER but still usable.  I’d estimate somewhere between 1 and 2 seconds per image.

BUT, switch to 1:1 and things compost.  With ALL palettes closed its several seconds from image to image.  With palettes open, it gets even worse.  I MAY get a “loading” indicator, but not always. 

TURN THE GRAPHICS PROCESSOR TO AUTO OR CUSTOM

Then shut down Lightroom and restart, delete all the 1:1 previews and recreate (not a quick thing with 2000 images)…

Go back to the Library and do the same thing I did last time – walking through images.  Still appears to work fine.  1:1 still seems to be ok.  For the small sample I examined, it wasn’t perceptibly slower, and it definitely doesn’t appear any faster.

But, in Develop things appear to be worse.  Even walking through images in loupe view is perceptibly slower and at 1:1 it’s extremely slow.  And using the local adjustment brush is painful – even the mouse is laggy and jerky, and any adjustments take seconds to take effect. 

At times when moving from an adjusted image to another image, the whole screen goes black for a period, then comes back, and at some point moves to the new image.  Doesn’t happen all the time, and I’m not sure what triggers it, but it periodically happens.

SO, at the moment I’ve got the Graphics Processor off.

Ahh, talking about item 7 in:

Nope.  Never allow LR to write to the XMP files…

You probably stated this already.  In the develop module, without accomplishing any edits. Does moving from photo to photo take a long time as if the preview had to be recreated?

If you mean not making ANY develop changes after creating the 1:1 images, as I said above, it’s still slow.  With a palette open (Solo mode) it’s even slower.  1:1 is even slower.

As near as I can tell, if I make a change to ANY image in Develop mode, from then on, movement through any of the images is EXTREMELY slow.  Purely a guess, but it SEEMS like changing any image caused ALL the 1:1 previews to be ignored, and even for images I haven’t changed it rebuilds the preview every time I touch the image even if it built it previously.  I have no idea if this is true, but I can see the CPU load jump from the normal 0 – 5% I see when things are quiet, to around 20% for several seconds while the image sits there, then drop back to 0 – 5%.  After that it switches to the new image and the mouse becomes active.

In Library module with loupe view active, moving from photo to photo. This also takes too much time as if previews are being created all anew? Might want to run thru that both in standard and say 1:1 view

As long as I DON’T make any changes in the Develop module, and I’ve pre-created the 1:1 previews, it’ll move OK in the Library, even at 1:1.  With standard previews, loupe view is OK, but 1:1 is extremely slow even with these small images.

I’ve changed my workflow for culling.  Previously I’d view images in either Library or Develop, and as needed, switch to Develop to make adjustment as part of the culling.  Needless to say, this is no longer possible.  Now I STAY in the Library module and view all the images.  Bad ones get a red label, those that need to be adjusted in Develop before deciding get a yellow label.  After deleting those that are bad from the Library I switch to Develop and make adjustments as needed, then either remove the yellow label if I’m keeping the image or changing it to a red label if I’ll delete it. 

Once I adjust the first image it’s extremely slow moving from image to image in Develop, and the lag time to see some adjustments is appalling, but I’m not looking at all the images, just a (hopefully) small subset.

One WIN OS LRC (and PS) performance tip I failed to mention. Location of your OS paging file vs Camera RAW CACHE and PS Scratch space (no effect on LRC). They should not be placed on the same drive.

OS wrighting to the Paging file could compete with LRC or PS wrighting to the Camera RAW CACHE or the Scratch space (PS). More of an issue with older non SSD.

Pagefile is on the SSD with the O/S.  LR catalogs, cache and PS scratch are on a different SSD.

One possible issue is antivirus. I have never ran into this issue. Possibility of antivirus getting in the way of the catalog. See the following posting. Apparently Windows Defender might behave poorly.

I suspect this is due to the Surface tablet, but either way, all the folders associated with catalogues, cache, and other LR operations are already excluded, as is the entire folder tree of the SSD that contains the image files.

Oh, and also in this posting, attached devices (USB) acting up, including but not limited to Android smart phones, Wacom tablets, Camera, Card reader, etc.

I don’t see anything in the post about problems with USB devices, but I suppose it possible that something is bad…  But, it’s not practical to run an editing system without USB devices like printers and such connected.  And there’s a Wacom tablet on here too, but I can unplug that.

Please provide your system information as shown by Lightroom Classic. In LRC click on Help, then System Information, then Copy. Paste that info in a reply. Mostly interested in info from first line down to just past plug-in info. Not one bit interested in info (gobblygook) after plug-in info.

Lightroom Classic version: 8.4.1 [ 201909111355-eb9b68f0 ]

License: Creative Cloud

Language setting: en

Operating system: Windows 10 - Business Edition

Version: 10.0.18362

Application architecture: x64

System architecture: x64

Logical processor count: 12

Processor speed: 3.3 GHz

Built-in memory: 32680.3 MB

Real memory available to Lightroom: 32680.3 MB

Real memory used by Lightroom: 10036.0 MB (30.7%)

Virtual memory used by Lightroom: 12621.8 MB

GDI objects count: 701

USER objects count: 1962

Process handles count: 3014

Memory cache size: 1443.8MB

Internal Camera Raw version: 11.4.1 [ 291 ]

Maximum thread count used by Camera Raw: 5

Camera Raw SIMD optimization: SSE2,AVX,AVX2

Camera Raw virtual memory: 4871MB / 16340MB (30%)

Camera Raw real memory: 4875MB / 32680MB (15%)

System DPI setting: 96 DPI

Desktop composition enabled: Yes

Displays: 1) 3840x1600

Input types: Multitouch: No, Integrated touch: No, Integrated pen: Yes, External touch: No, External pen: Yes, Keyboard: No

Graphics Processor Info:

DirectX: NVIDIA GeForce GTX 970 (26.21.14.3602)

Application folder: C:\Program Files\Adobe\Adobe Lightroom Classic

Library Path: L:\short term\short term.lrcat

Settings Folder: C:\Users\nnn\AppData\Roaming\Adobe\Lightroom

Installed Plugins:

1) AdobeStock

2) Aurora HDR 2018

3) ColorChecker Camera Calibration

4) DNG Flat Field

5) DNG Recover Edges

6) Facebook

7) Flickr

😎 HDR Efex Pro 2

9) Helicon Focus Export

10) Luminar 2018

11) Nikon Tether Plugin

12) Show Focus Points

Also a few inquires the system information will not be clear on

1. The drive the catalog is on, how much free space in percent? Looking fir at least 20%

Catalog is on a 175GB partition of a Samsung 840 EVO SSD.  Free space is currently 91GB, 53%. 

Images are on a separate 4TB EVO 860 QVO.

O/S, applications, temp, everything else is on a 1TB SSD

The only spinning platters in the system are the internal backup drives.

2a. How many photos in the catalog (this as context for other questions)

Approximately 250.  Catalog was created and populated with approximately 1800 images for culling.  Performance appeared the same with 1800 as 250.  1:1 previews created immediately after import.  Images culled and a subset edited in Develop.  1:1 previews deleted and recreated on the 250 remaining images in an effort to improve performance.

2b. How large are your average photo? (hard drive space not sensor size)

These are smaller images, shot on a Nikon D850 at 1.2X, so they average around 36MB as opposed to normal D850 images at 53-54MB.  Have seen the similar performance with 19MB images from a Nikon D500, though I don’t recall it being as bad.

1. How much space have you allowed for Camera RAW CACHE (relates to 2a and 2b)

Cache is set at 25GB and is on the same SSD as the catalogs.

4, When did you last optimize your catalog?

Yesterday, after the majority of images were culled.

1. Do you keep those xmp sidecar files? (bad)

Once the culling is complete, metadata is written to the images, and the images are converted to dng prior to importation into the Image catalog. 

1. Have you allowed LRC to create all library standard previews and 1:1 previews?

Standard previews are created at import, when copyright, camera profile, lens profile, sharpening to 0, color noise to 15 are applied.  After import, 1:1 previews for all images are built.

1. How large are your standard previews set to? (catalog setting?)

Catalog settings for standard preview is “Auto(3840px)”, quality Medium.  I have tried smaller previews at 2880 (which was the setting used for the 30”, 2560x1600 monitor).  Did not appear to make any difference that I can recall.

As this is a Windows rig. look ar your advanced power settings. It should not be set to the default setting of balanced. Set it to High Performance. Be aware that OS updares tend to reset this to default. See item 1 in:

Power settings have always been set to “Performance.” 

Wireless Adapter Settings, Power Saving Mode:  Maximum Performance

Link State Power Management: Off

Processor power management: Minimum processor: 100%, Cooling policy: Active, Maximum processor: 100%.

Unnecessary notifications are disabled.

OneDrive is not in use

No Windows indexing is being performed (Windows Search is Disabled)

Storage Sense is running but has rarely deleted anything.  Disk Cleanup is run approximately weekly, including cleaning system files.

Malwarebytes is run regularly to check for issues.

CCleaner is regularly run to clean up system and registry.

Bloatware has always been gone – apps, xbox, etc.

I didn’t find anything in any of the tuning links that hasn’t already been done.

And, NVIDIA GTX 970. Is that v 436.30? Assuming you are using the default game ready drivers.

I haven’t found version 436.30 so I’m running the August update 436.02.  I’ll see if I can find 436.30 and put it on…