Skip to main content
Known Participant
September 25, 2017
Question

Performance - From a Computer Science Point of View

  • September 25, 2017
  • 74 replies
  • 2149 views

Like others, I am having a frustrating time with Lightroom editing photos from a performance standpoint.

My workflow typically has me creating a new catalog for a particular photo shoot, importing the (RAW) photos and applying a custom preset on import and then editing the photos one by one in the Develop Module.

After editing a number of photos (say, 10-25) the performance of Lightroom degrades significantly and I have to exit Lightroom and re-start it to continue editing (and continue to do so until I have completed my editing).

I have done significant research into Lightroom performance issues and have tried all of the suggestions and all possible permutations thereof to no avail.  I have also profiled Lightroom with a number of Windows development tools to take a look at it's I/O, threads, memory, etc. and nothing specifically stands out.

I do understand that Lightroom stores it's editing changes (whether via a preset or manually) in a SQLite database and then applies these changes to a photo in 'real-time' to render what you see on the screen.  That leads me to believe that the program is having a difficult time querying the database and applying the changes in 'real-time'... it is almost like there is a 'leak' as one moves from one photo to the next.

Edit: I took a quick look at the Lightroom .lcat file which is actually a SQLite database.  In it, I found 102 tables.  Still looking at the relationships between these tables.

All of the suggestions to add faster disks, larger caches, build previews, etc. are all masking the real culprit which I believe is an internal data structure, database, etc. issue.  My 'evidence' for this is that exiting and re-invoking Lightroom will always provide me great performance until I reach 10-25 photos and then I have to 'rinse and repeat'.

What I would like to know from the Lightroom software development team is whether there is a way for uses to 'peek' inside the program to know what is actually going on from an operating system and computer science perspective (open files, memory allocation, threads, locks, etc.).  I would assume that the Lightroom software development team knows exactly what is going on as the program is likely instrumented.  Knowing what it is that is causing Lightroom to gradually degrade its performance will help users understand how our behavior might need to change when using Lightroom to improve our experience (like perhaps not/not applying presets to hundreds of photos at once rather, do so as you edit one photo at a time).

I do love Photoshop and Lightroom and recommend the products to everyone that ask me for advice but I also believe that Lightroom's performance issues are serious and need to be addressed.

Thank you for your consideration

This topic has been closed for replies.

74 replies

Participating Frequently
May 15, 2018
If Adobe would show you the internal processes they would have to change the name to Lightroom middle ages.
Thats why disabling the gpu support solves so much issues
Participating Frequently
November 29, 2017
Guys, take a look at my last post. Maybe it could be relevant to some of you.
https://feedback.photoshop.com/photoshop_family/topics/lightroom-classic-cc-develop-module-still-slo...
fingham1Author
Known Participant
November 7, 2017
Alan/Joel,  I have used the SysInternals programs as well as Visual Studio (debug programs) to profile Lightroom and you CAN get a lot of information on where there is resource contention and high CPU usage however, without the Lightroom symbols, it is impossible to see exactly where the issues is/are - instead, you will see what .dll (CameraRaw.dll) and resource ('handle 15', etc.) are at issue but for more insight, we need the symbols.  You will also see that DNG C++ library exceptions are thrown quite a bit.  The last part is interesting - I do not utilize .dng files however, Lightroom must use that library to store our edits (in addition to storing them in the underlying SQLite database).
Community Manager
November 7, 2017
I'll try when I have a chance..
Participating Frequently
November 7, 2017
Joel Weisbrod I'm not a coder so... what about trying just process explorer and process monitor from sysinternals? To evaluate process threads and stacks..to find something more specific.
fingham1Author
Known Participant
November 7, 2017
To those that have looked at the performance of LR with the Visual Studio product, were you able to successfully get the LR symbol files for their DLLs?  I am seeing some interesting contention for resources and exceptions being thrown in the code but without the symbols, it is hard to determine exactly where it is occurring.
john beardsworth
Community Expert
Community Expert
November 6, 2017
Great theory. Just one problem - LR was mainly Lua before people were complaining about severe slowdowns, and it remains so when some people are.

One of the most frustrating aspects is that some people clearly have problems, others don't, and there is no single source of the slowdowns. I had one case where clearing the entire Develop History miraculously resolved severe slowdowns in Library and Develop, and in other cases the very-expensive VCSO presets were what reduced LR to a crawl. I would recommend trying both these solutions, but we should not need such voodoo.
Community Manager
November 6, 2017
I wouldn't hold my breath!
Community Manager
November 6, 2017
Without the GPU. it takes longer for the slowdown to start but it still slows down. As a side note, on my PC (Win 10/64 Creator's Edition (was the same before the Win Upg), Core i7 3.3Ghz with 12 Cores, 64Gb 2400Mhz RAM, Dual 1Tb SSD Drives, NVidia Titan Graphics with 12Gb Dedicated VRam, Dual 1920x1080 LG IPS Monitors - not even 4k or 5k - heaven forbid) Capture One is lightning fast and so is everything else I use except for Lightroom.
New Participant
November 6, 2017
definitely beyond standard LR slowness 🙂 It must be something in your hw/sw that LR really doesn't like.
That's what I was thinking, too, when I just saw the video! This is WAY worse than the slowness I'm experiencing. Keeping fingers crossed that there is a quick solution for Joel... 😞

I will now give it a try using the OpenGL-thingy on my system.