CC App 13.5 performance issues

[atolkachev]

13.5 is all but unusable right now after a modest 1300 photo import. These issues were present in 13.3 and 13.4.

Fetching initial previews taking forever, with no progress shown for a long time. Eventually completed. Something like 20 minutes.

Writing XMP is like one file per two seconds.

Edits disappearing. Not permanently, but it takes a long time before they resurface. Use case: apply edit to a photo. Switch to Library module, go to the next photo, come back to the edited photo, switch to Develop. Edits are not there, and History is empty. Wait 5 minutes. Edits resurface and History populates. Ridiculous. Hit right arrow -- photo does not switch. Hit right arrow again -- nothing. Switch to Library -- shows you have advanced by two photos, but Develop module was not reflecting it.

Select a few photos and hit Sync Settings. Nothing happens for five minutes. Can still switch between photos, edit, etc. In 5 minutes the Sync dialog pops up.

Hit Quit. It says "Writing Metadata Changes into XMP. Please wait until the process is complete." Progress goes up up .1% every 2-3 seconds. It is still up, I have had the time to catch up on the forum and write this post.

Sure, my catalog may be corrupt or hard drive failing. How would I know?

This misery started around 13.3. Cloud sync is another nightmare. The first thing I did was paused synching after the import so all this other backround crap can catch up.

I am on MacBook Pro, OP is Windows, so I don't know.

 

[inyvrszf5]

13.5 is all but unusable right now after a modest 1300 photo import. These issues were present in 13.3 and 13.4.

Fetching initial previews taking forever, with no progress shown for a long time. Eventually completed. Something like 20 minutes.

Writing XMP is like one file per two seconds.

Edits disappearing. Not permanently, but it takes a long time before they resurface. Use case: apply edit to a photo. Switch to Library module, go to the next photo, come back to the edited photo, switch to Develop. Edits are not there, and History is empty. Wait 5 minutes. Edits resurface and History populates. Ridiculous. Hit right arrow -- photo does not switch. Hit right arrow again -- nothing. Switch to Library -- shows you have advanced by two photos, but Develop module was not reflecting it.

Select a few photos and hit Sync Settings. Nothing happens for five minutes. Can still switch between photos, edit, etc. In 5 minutes the Sync dialog pops up.

Hit Quit. It says "Writing Metadata Changes into XMP. Please wait until the process is complete." Progress goes up up .1% every 2-3 seconds. It is still up, I have had the time to catch up on the forum and write this post.

Sure, my catalog may be corrupt or hard drive failing. How would I know?

This misery started around 13.3. Cloud sync is another nightmare. The first thing I did was paused synching after the import so all this other backround crap can catch up. compass mobile.dollar tree.com schedule

I am on MacBook Pro, OP is Windows, so I don't know.

That sounds really frustrating! It seems like there could be a few things causing these slowdowns. Have you tried optimizing your catalog or checking the hard drive for errors? Sometimes a corrupted catalog or failing drive can cause Lightroom to lag like that. Also, maybe try resetting preferences or disabling GPU acceleration in Lightroom to see if that helps. Hope you get it sorted out soon!

 

[Gnits]

Writing XMP is like one file per two seconds.

Why specifically are you writing XMP ???

 

[drgrba]

It could be a catalog or system performance issue.

 

[SdeGat]

Why specifically are you writing XMP ???

Can we get rid of the XMP files? They started to appear in a recent version upgrade.
We don't need them, do we?

 

[clee01l]

Can we get rid of the XMP files? They started to appear in a recent version upgrade.
We don't need them, do we?

XMP files have never been required and the XMP checkbox has not changed from what the user sets in preferences. If they started to appear for you , then it was a user made change.

Many people set LrC to automatically write XMP to the original file or side car with the mistaken belief that those edits are a safteey feature incase the Catalog file is corrupted, when the best safety feature is Lightroom;s Backup copy on exit. You can never have too many Backup catalogs. while XMP only writes some of the metadata to the XMP.

 

[thegios]

Well I'm not alone then even if people keeps on saying it's my HW not being capable, yet I have i7 13700 32GB RAM SSD RTX 3050. LrC developers must have smoked a lot before writing code recently given I have lots of UI slowdowns even for basic tasks. What drives me crazy is that slowdowns come at random, sometimes it's enough to close and reopen LrC to solve the issues. I'm sure there are memory leaks...

 

[Gnits]

This is a complex topic and we all have our own personal workflows.

We now have 60-100MB cameras, rendering images on 4k,5k and 8k screens. At the same time we can shoot 120 frames per sec (most people do not).
Recent and extremely useful filters in Lr now allow us to avoid round trips to Photoshop (and also creating large intermediate files). But we may forget that these filters require substantial amounts of interactive memory and disk storage. In many cases multiple filters are applied to the same image, It is not a surprise that this will be more demanding on hardware. The hardware load increases substantially when some one opts to save xmp data to disk.

There are perfectly good reasons to save xmp data to disk, but the vast majority of people do so without a clear reason. Much more efficient and manageable is to have a good workflow in terms of backing up the catalog. If you do need to save xmp to disk… why not run this option as a batch process at the end of an editing session or overnight, rather than overload your cpu and disk I/o and database I/o in realtime as you edit.

 

[thegios]

This is a complex topic and we all have our own personal workflows.

We now have 60-100MB cameras, rendering images on 4k,5k and 8k screens. At the same time we can shoot 120 frames per sec (most people do not).
Recent and extremely useful filters in Lr now allow us to avoid round trips to Photoshop (and also creating large intermediate files). But we may forget that these filters require substantial amounts of interactive memory and disk storage. In many cases multiple filters are applied to the same image, It is not a surprise that this will be more demanding on hardware. The hardware load increases substantially when some one opts to save xmp data to disk.

True but last three version have not introduced anything really new, so if my computer was running fine 4 versions ago and started having problem since three versions ago then the problem lies in LrC source code

 

[Gnits]

Fair point.

 

[clee01l]

Well I'm not alone then even if people keeps on saying it's my HW not being capable, yet I have i7 13700 32GB RAM SSD RTX 3050. LrC developers must have smoked a lot before writing code recently given I have lots of UI slowdowns even for basic tasks

I'm not sure I should even honor this post with a reply, But I will say this. The vast majority of LrC users, even Windows users do not have issues. It is not realistically possible for Adobe to test the almost endless number of permutations and combinations of Windows Hardware configurations. Perhaps your system is unique in it hardware configuration. Perhaps not.

"The last three version have not introduced anything really new". This is completely incorrect. LrC v13.3 introduced a completely new sync Process and this has caused problems for some, especially those that were automatically writing XMP metadata to files.

 

[atolkachev]

I disabled XMPs. There is a separate performance issue associated with a medium size (e.g., 1500 images) import and batch editing -- pasting or syncing settings from one image to many. After the last such import and initial mass edit, my LrC did not become fully usable for three days.

 

[PhilBurton]

It is not realistically possible for Adobe to test the almost endless number of permutations and combinations of Windows Hardware configurations.

And don't forget the number of supported versions of Win 10 and Win 11, and PATCH LEVELS, for all those different configurations of hardware. And differences in driver versions. (Same issue also present with MacOS).

Perhaps your system is unique in it hardware configuration. Perhaps not.s.

If we want to get really, really down in the dirt, we could ask people to post their experience with Lrc 13.5 (not older versions!!), and details of their hardware, such as manufacturer and system name, CPU model, RAM, storage, and GPU or integrated GPU in the CPU. Plus Win OS details. For homebuilt systems, the motherboard manufacturer and model, and the hardware bits just listed.

As the Bard said in King Lear Act 3, scene 4, 17–22

Lear:

O, that way madness lies; let me shun that;

I am NOT volunteering to start or lead this effort, but maybe someone more selfless than I am could do this.

 

[thegios]

Dears, as a 52 year old computerscience engineer I partly disagree... But I'm tired of explaining why on the whole internet... All I know is that a 2.000€ pc built 16 months ago all of a sudden has started having ransom LrC after an upgrade that brought no real new features to me (I don't use sync btw). Now if problema were constant, your points stand true, but being at random, being solvable by restarting LrC and a few other inconsistencies, I'd rather tend towards bad source code. Pity it's too late to move to competitors...

 

[clee01l]

Dears, as a 52 year old computerscience engineer I partly disagree.... Pity it's too late to move to competitors...

It is never too late to move to the competitors. But AFAIK, there’s are none. ON1 and Topaz offer excellent editing products. I use both along with LrC. There might be alternative image management products. Apple has a platform sharing solution that is fine only as long as you use Apple hardware. But there is not one solution that combines all three except Adobe.

FWIW, I’ve been a retired application developer (Computer Science engineer sounds too pretentious) probably longer than then you have been in the business. In the intervening 15 years since I retired, Quality Testing must have gotten better and there must be fewer possible platforms to test for apps to be released with fewer bugs. Any application developer should recognize that there are no updates that are bug free.


Sent from my iPad using Tapatalk

 

[SdeGat]

XMP files have never been required and the XMP checkbox has not changed from what the user sets in preferences. If they started to appear for you , then it was a user made change.

Many people set LrC to automatically write XMP to the original file or side car with the mistaken belief that those edits are a safteey feature incase the Catalog file is corrupted, when the best safety feature is Lightroom;s Backup copy on exit. You can never have too many Backup catalogs. while XMP only writes some of the metadata to the XMP.

Thanks for the "vote of confidence" @clee01l
I did not change the XMP setting and actually had to Google it to find where it was.
And it is not checked!

But I am still stuck with hundreds of XMP files in the folder from my last photoshoot. And not the previous ones.
Can I just delete the XMP files or will I loose my edits?

 

[karl.nyhus]

Other programs write XMP sidecar files besides Lightroom. For example, Photo Mechanic, FastRawViewer, and Adobe Bridge have all written XMP sidecar files on my photos before I ever got around to editing them.

 

[Gnits]

As far as I am aware, Photomechancic just stores a few small text snippets such as rating, maybe Title and similar. Lightroom has to store the complete develop settings, incl all masks (ie large blobs of data) etc associated with ai based filters. The principle is the same but the scale and complexity are different.

 

[clee01l]

Other programs write XMP sidecar files besides Lightroom. For example, Photo Mechanic, FastRawViewer, and Adobe Bridge have all written XMP sidecar files on my photos before I ever got around to editing them.

And if not an Adobe app, the XMP may not be usable by any Adobe apps like Photoshop.

To the OP: If you have edited the image in LrC then all of those edits are in the catalog file. This is why XMP files are not necessary or efficient for LrC.

Any Adobe XMP sidecar files can be deleted if LrC is used as the editing tool. When LrC uses the Edit in function to send an image (like a Smart Object) to Photoshop, if Photoshop requires the LrC edit adjustments, a new XMP will be created.

XMP files created by other apps can be deleted if you have no use for them. You can ope any XMP file in a text editor to determine if the content is useful or can be discarded.


Sent from my iPad using Tapatalk

 

[atolkachev]

That sounds really frustrating! It seems like there could be a few things causing these slowdowns. Have you tried optimizing your catalog or checking the hard drive for errors? Sometimes a corrupted catalog or failing drive can cause Lightroom to lag like that. Also, maybe try resetting preferences or disabling GPU acceleration in Lightroom to see if that helps. Hope you get it sorted out soon!

Optimizing catalog, yes. Checked the hard drive (SSD) just now using FirstAid, nothing. Tried with and without GPU acceleration.

As I mentioned above, it takes three days after import for LrC to become responsive and reliable, and I am currently in that state. But another import is coming tonight, and the biggest issue right now is sync, which seems permanently stuck. Of the last import, only 389 photos of 1083 made it to the cloud.

Performance and sync issues take turns being my biggest bane. After import, it's performance. A few day later, it's sync. I am not sure if these issues are related or not. I tend to keep sync paused while trying to work through performance issues.

At least I got rid of XMP writing. I was fairly sure LrC pushed them on me, but if others are reporting that this setting is off by default, it could have been a self-inflicted injury.

 

[SdeGat]

Optimizing catalog, yes. Checked the hard drive (SSD) just now using FirstAid, nothing. Tried with and without GPU acceleration.

As I mentioned above, it takes three days after import for LrC to become responsive and reliable, and I am currently in that state. But another import is coming tonight, and the biggest issue right now is sync, which seems permanently stuck. Of the last import, only 389 photos of 1083 made it to the cloud.

Performance and sync issues take turns being my biggest bane. After import, it's performance. A few day later, it's sync. I am not sure if these issues are related or not. I tend to keep sync paused while trying to work through performance issues.

At least I got rid of XMP writing. I was fairly sure LrC pushed them on me, but if others are reporting that this setting is off by default, it could have been a self-inflicted injury.

I'm in a similar situation.
I get a delay when typing "G" for grid before I get the grid on screen.
Typing "Q" for the healing tool sometimes takes seconds for the healing cursor to appear (and disappear).

It's hell really.

I even bought a new GPU to ensure that wasn't the issue (GeForce RTX 4070).
That didn't change anything really. (Except for specific operations like Denoise for example).

My computer is somewhat older than the OP but it is an Intel Core i9 9900K @ 3.60GHz with 32 GB or RAM. My C: drive is a Western Digital WD_BLACK SN750 2TB giving me good transfer rates.

It's got to be some kind of setting somewhere.

 

[karl.nyhus]

As far as I am aware, Photomechancic just stores a few small text snippets such as rating, maybe Title and similar.

And if not an Adobe app, the XMP may not be usable by any Adobe apps like Photoshop.

The apps I mentioned write metadata, not adjustment settings, to XMP sidecar files. These are the same files, if present, to which Adobe's apps write their adjustments and metadata if user settings so dictate.

XMP sidecar files all look the same from the outside. It was not clear to me what the poster knew about the contents or origin of the XMP sidecar files being complained about.

 

[clee01l]

The apps I mentioned write metadata, not adjustment settings, to XMP sidecar files. These are the same files, if present, to which Adobe's apps write their adjustments and metadata if user settings so dictate.

XMP sidecar files all look the same from the outside. It was not clear to me what the poster knew about the contents or origin of the XMP sidecar files being complained about.

The Adjustment setting are also considered metadata. Edit adjustments for editors other than those used by Adobe won't be understood by Adobe or vice versa, that is why I said "You can open any XMP file in a text editor to determine if the content is useful or can be discarded."

XMP files are a standard text file using the Extensible Markup Language (XML).

 

[karl.nyhus]

that is why I said "You can open any XMP file in a text editor to determine if the content is useful or can be discarded."

I do that all the time using the BBEdit app but any plain text editor will do. And if I did something to cause a sidecar file to be written on one of my photos, it is probable that I want to keep it. Adobe can write its adjustments into that same file.

 

[SdeGat]

I’ve been reading a bit about LrC performance issues as I have had that problem for a long time and came across Windows 10/11 indexing potentially being in cause.

Would anyone be aware of that Windows problem? From what I could see, it is not yet solved…