Lightroom: Performance and optimization: LR is slow

  • 201
  • Problem
  • Updated 3 years ago
  • (Edited)
LR 4 is excruciatingly slow. Until Adobe is able to do something about this I am recommending my students and readers continue to use LR 3 or switch to Aperture.
Photo of STEVE ANCHELL

STEVE ANCHELL

  • 16 Posts
  • 1 Reply Like

Posted 6 years ago

  • 201
Photo of David Perez

David Perez

  • 26 Posts
  • 2 Reply Likes
They could be. Although, I suspect a "quiet rejiggering" isn't going to be sufficient. Unfortunately, it seems to me there's more interest for things like "books" and "maps" than in making SIGNIFICANT performance improvements in Library and Develop.

But, as it is, it mostly works... Poorly on my i5-720, 16GB laptop, somewhat better on my i7-920, 24GB desktop. Although lately the desktop has been performing pretty poorly, too. Lots of glitchy behavior, even had LR crash the other day because it "ran out of memory" while generating 1:1 previews.

But, it is what it is. The 800 pound gorilla sits wherever it wants.
Photo of Mark Thomas

Mark Thomas

  • 36 Posts
  • 1 Reply Like
Let me just say that, unless I install too many presets, Lightroom runs fine for me even on my old Core 2 Duo MacBook Pro from 2009. So even if it is slow on your particular hardware, it’s not inherently slow for any particular reason.
Photo of Diko

Diko

  • 77 Posts
  • 9 Reply Likes
I have a dozen of custom presets and the ones coming with the LR. And still no improvement there :-(
Photo of David Perez

David Perez

  • 26 Posts
  • 2 Reply Likes
Mark, I'm not sure in what context your Mac runs fine. So, as an experiment, open a raw file from the largest format camera you're using - preferably one from a Nikon 800 or close Canon equivalent. Open the file in LR 5.6. Go into develop and make normal bunch of Basic adjustments. Go to HSL and make normal bunch of adjustments. Do noise reduction and sharpening. Do lens corrections and so on... Do the adjustments a couple times. Does it ever lag or slow down or hang?

Now go back to basic and start "healing" areas. Do a bunch. As quickly as possible. Think healing dust and spots, so it would be very fast activity. Does it ever lag or slow down or hang? No go to the adjustment brush. Do the same kind of thing - select a moderate area. Change the exposure. Repeat as quickly as you'd normally work. Does it ever lag or slow down or hang?

If not, you're right, it runs fine. If it does, welcome to the world others are seeing.
Photo of Mark Thomas

Mark Thomas

  • 36 Posts
  • 1 Reply Like
It’s pretty rare that I do that much tinkering with an image. I keep Sharpening and Noise Reduction at their defaults and never touch them. The only lens corrections I apply are Remove Chromatic Aberration and sometimes Distortion correction for a horizon. Occasionally I’ll Heal some sensor spots. Very rarely will I use the Adjustment Brushes. I try not to overdo this stuff.

I think you’re overworking your images and looking for trouble if you push Lightroom as hard as you describe. I could say that I’m reasonably fit for 45, and go for a 3 mile walk most evenings, but if you forced me to run that distance wearing a 50 pound pack and jogging weights, I’d get tired quick. It doesn’t mean I’m out of shape, though.

To improve your situation, why not just turn off Noise Reduction and Lens Corrections while you use the Adjustment Brush, and turn them back on when when you’re done?
Photo of David Perez

David Perez

  • 26 Posts
  • 2 Reply Likes
I totally disagree. Watch any of the well known instructors at Creative Live, Digital Photography School, Lynda.com, and several other local instructors, as well as the LR developers when they attend user groups to tout the product. You'll see them do ALL the things I suggested and MORE. And more extensively. Supposedly, LR was MADE to do these things. And they're where most people that see problems, see them. I suspect this is a good example of why most discussions in any topic here have such diametrically opposed viewpoints.
Photo of Ron Hu

Ron Hu

  • 45 Posts
  • 2 Reply Likes
Now for any NOT on Win7 or preferably 8.1. Use them.

You can't tell what anything is doing w/o profiling it and then it takes an EXPERIENCED Eye to know where the bottle-necks are.

All the 'users' here can complain and all the devs can say is "its not that", but until profiled ETL tracing is done AND analyzed would one be able to provide an pretty accurate description of the 'why' its slow.

My setup is OS drive and C:\users| are o a R0 SSD, C:\Users\ is mounted on its own SDD (where catalog is and back cats are located)
HDD: is where my raws/xmp's are.

Also we never mention or possibly remember LR is highly dependent or *is* mostly camera-raw. This is mostly likely where the complaints should be addressed. Since its is my understanding its the real work horse here.
Photo of David Perez

David Perez

  • 26 Posts
  • 2 Reply Likes
Ron are you saying the problem is with the handling of the various manufacturer RAW images? If so, does this mean LR is better able to handle .dng files since they're an Adobe construct and thus if images are loaded into LR as .dng files, the problems causing the complaints wouldn't occur?
Photo of Ron Hu

Ron Hu

  • 45 Posts
  • 2 Reply Likes
I didn't say anything like that. I don't recall mentioning and after re-reading what I wrote could a person thing I was talking RAW over DNG. I never convert my images to DNG. CR2 files are just compressed TIFF is my understanding anyway. So I don't worry about needing to read DNG over CR2 in 100 years from now.

;) by then they could probably get the images from your Brain directly at that point. :D

Optimizing software by the implications of the word, means picking a winning configuration at the expense of another or others. With the number of various CPU, memory, and disk subsystems. One can only so do much.

Compiling for Intel runs the risk of the compiled code to not run well on AMD. As a further example you could pick the I7 and if GCC compiler then particular generation. Then you've made the code GREAT on that processor and newer, but really bad on all others, to the point it may not even run as the code will have instructions that don't exist.

So that is why you pick a MIN. hardware config to run and say here is the bottom line. Must have equal or better to run. Then one looks at the CPU out there that make up the overall usage numbers and then of the power users. They one could have the discussion of where to optimize for a CPU family.

Compiling code is most often simplified to "blended" meaning the instructions chosen run on the widest CPU versions. The code sequencing isn't optimized for Intel over AMD or even for one processor type over the others. Its as generic as it gets.
Photo of David Perez

David Perez

  • 26 Posts
  • 2 Reply Likes
Ron, I must have misread your initial response... I read that since LR is highly dependent on "camera raw", and that's where the complaints should be addressed... To me, that meant "camera raw" is a likely/possible problem area. Thus, my question that if camera raw is the "real work horse", would a format created by, and I presume, made to be optimized and fully supported by Adobe's soft ware be a better option.
Photo of Andrew Sible

Andrew Sible

  • 7 Posts
  • 0 Reply Likes
I was brought here from adobe forums and I'd like to voice my horrible experience. I'm waiting for images to sync while I type this. I did a basic temp adjustment to about 100 images and it's running like snail snot.

I have to reboot LR5.6 to get it to speed up marginally, and it bogs again after 30 minutes. LR5.4 had no issues, and I've not changed anything with the program except one plugin that I've since disabled. The updates were the ONLY difference between a usable LR5.4 and the completely horrid LR5.6

I'm straining to get these images done for my client and I will be attempting to downgrade to LR5.4. Really disappointed here...

LR5.6, 8GB ram normally 32GB (have some out for testing because I was worried it was a ram issue, and it's not. I haven't put them back in yet), SSD with my OS, and a 4tb HHD for main files. Intel i7 3770k CPU, integrated HD4000 GPU. Dual screens, slightly old display driver (intel mucked up on a recent one, I won't be updating unless I have to because it might break my two-monitor functionality)
Photo of William Anderson

William Anderson

  • 35 Posts
  • 7 Reply Likes
Andrew, you didn't mention the brand and size of your SSD? Not all SSDs are equal and in fact they have a very wide range of performance characteristics. If your catalog and the preview files are on the OS SSD, that could be your bottle neck.

If you're tight on space, the SSDs can really bog down when an application starts to perform high write counts. That's because SSDs never write data back to it's original space, it writes it to a new location and marks the old as garbage. The operating system has to come back and issue a TRIM command to the drive to recover garbage space.

During any adjustment made in Develop mode, LR 5 will write to several SQLight DBs and at least one cache entry. That's for every single movement of a slider or the click of a checkbox. Every, and I mean Every click of the mouse causes several writes to the catalog/preview files. Very few read operations take place during a Develop session.

SSDs are not well suited to high write activities, so I would suggest you look to your SSD as part of your problem.
Photo of Andrew Sible

Andrew Sible

  • 7 Posts
  • 0 Reply Likes
Thanks for your input, I have a OCZ Vertex 4, so no problem with speed.

That being said, your suggestion is similar to what others have suggested; yet like others with this issue, I had no problems with this horrible lag prior to updating Lightroom from 5.4. Thousands of images, regular use, proper setup. I was mostly fine except lightroom became unstable likely due to a ram issue which I've resolved. The crashes were workable though, while this is so bad I almost cannot batch edit.

So in other words, 5.4 was ok. Now with the 5.6 update, it's just unusable. I do believe it's lightroom because others have the exact same issues as me, reported in this thread: https://forums.adobe.com/message/6701...

Different GPUs, CPUs, OS, Ram...etc...

I have 25gigs of free space free by the way, so garbage shouldn't be a problem, and I'm not worried about the write activity it shouldn't be an issue in this rig's serviceable lifetime.
Photo of David Perez

David Perez

  • 26 Posts
  • 2 Reply Likes
I've noticed the same thing, but it seems like I saw similar behavior in 5.5 too. I'm now having to shut down LR periodically and restart it because it just keeps getting slower. I don't recall seeing this level of degradation on earlier versions, but I'm not sure if it was 5.4 or earlier when it ran better.

And I'm on a Samsung EVO 840 SSD that's just over half full. It contains the O/S, applications, and catalog. Cache and images are on separate 7200 rpm platters.

I'm having a hard time believing that any, properly operating SSD, unless it has no free space, is going to be a "bottleneck" compared to a spinning platter, but I'm not an expert in I/o storage architecture. I do recall that when LR 5 came out, it seemed like a GREAT MANY "it's slow" complaints in the Adobe forums were responded to with "GET AN SSD"
Photo of Andrew Sible

Andrew Sible

  • 7 Posts
  • 0 Reply Likes
I agree, SSD is not the issue or LR5.4 would have worked poorly as well. HDD architecture should have no issue and if anything speed up response unless your scratch drive is full.

I think this is simply a driver compatibility or optimization bug that Adobe introduced inadvertently when they updated other things. I just wish I knew why some report no issues while a good group of us have the same, consistent "must shut down LR periodically and restart it" issues.

Once I upload this latest job I'm throwing in the towel and downgrading to LR5.4 and I'll hopefully have time and patience to report back. I wasn't enthusiastic about LR's performance to begin with but it was tolerable for all it did for me. Now however, I'm just so frustrated with LR, because I don't have time to troubleshoot for a week out of every month.
Photo of Steve Sprengel

Steve Sprengel, Champion

  • 2586 Posts
  • 323 Reply Likes
The slowing down of LR after a while sounds like resource exhaustion. One user, a version or two, ago, found that LR 5.x leaked GDI Object handles on Windows and when LR got to around 10,000 it crashed, but slowed down somewhat before that. And any program that is leaking memory will eventually start using too much virtual-memory and will grind to a halt.

So before you ditch LR 5.6, look in Task Manager, for memory and GDI Objects – you may have to add columns in Task Manager to see all the memory items or GDI Objects, and record their values at the beginning of a session, a ways in but before things slow down too much, and then one more time by the end when they are slow and you’re needing to restart. Probably record LR’s and also the general RAM (Physical/Virtual) numbers on the Performance tab.

I have seen no problems with LR 5.6 that I use almost daily, but my editing patterns may be entirely different than yours and there may be just one place that leaks resources and I’m not using it while you may be.

If you are seeing some sort of resource exhaustion there may be something Adobe can fix, but specific information will be useful for them to track it down. Once you know what resource is being used up then precise tracking of that resource (RAM/GDI) during your editing will help find the area.

The other thing I’d suggest is to go back just one LR version to 5.5 and see if that version has the problem. It’d be easier for developers to narrow down what is happening if they know precisely which version the issue started happening.
Finally, you can make it easier to test if you keep LR 5.6 on your system while at the same time using the older version, so you can switch back and forth between the two—I mean it’s possible that using the older LR 5.x won’t fix things, and it’s an environmental issue with your catalog or preferences. The way to do this is to rename the Program Files\LR 5.6 folder to something else, before installing LR 5.5/4, so that install doesn’t remove the newer LR 5.6, then after installing the older LR, rename the LR 5.6 folder back. You can do this for both the 32-bit (PF-x86) and 64-bit (PF) folders to preserve both versions.

If you do have something concrete to report, then I’d start a new thread with specifics in the subject like GDI Resource Leak in LR 5.6 vs LR 5.4 or whatever it is. This would allow Adobe to notice the specific issue, rather than having all the discussions lumped into a many months/years-old thread that covers many issues and versions.
Photo of Andrew Sible

Andrew Sible

  • 7 Posts
  • 0 Reply Likes
THANK YOU Steve that's some good information that I can understand and use to work with multiple LR versions. I was wary about downgrading and wasn't sure how to maintain my settings and seamlessly switch.

I didn't know about GDI objects but currently LR is at 688, with 4.7 of 8GB RAM filled, so it's not the 10k you mentioned nor is it filling ram, but I'll keep track of it.

I have maxed out ram so I will attempt to test my remaining ram sticks and replace the known good ones. I'm sadly dealing with two issues at once here, I have RAM errors somewhere in 32GB of ram so I've been forced to find one good stick of 8GB and run with that during this job.

Soon I'll do my best to get concrete evidence and data on this error and post a new thread, thanks for your assistance.
Photo of William Anderson

William Anderson

  • 35 Posts
  • 7 Reply Likes
Steve, very nice breakdown. I'm convinced that the results of any testing will yield the same conclusion that I have: memory management and file handling are at the crux of most performance issues in LR.

LR was designed for use on the tiny (by today's standards) RAMs and HHDs available 15 years ago. As such there are many opportunities within the system infrastructure for things to go south.

The application/GUI works pretty well; the memory and file handlers, not so much. That is not likely to ever change for this product.
Photo of Steve Sprengel

Steve Sprengel, Champion

  • 2579 Posts
  • 323 Reply Likes
A resource leak would be a mistake in coding, not a design issue, although I'm sure there are design issues, but LR's code has surely got to be very messy after this many years, so mistakes are bound to be made.

Each LR version seems to be optimized for performance a little differently than before, and some of those optimizations are to cache things in memory so even if there aren't mistakes, per se, memory will get fragmented beyond what the garbage-collection can consolidate and some memory will be lost over time, until it is all freed up upon exit.
Photo of Mark Thomas

Mark Thomas

  • 36 Posts
  • 1 Reply Like
I've got a quad core i7 Mac Mini with 16 GB of RAM and a 1TB Crucial SSD, and while most of the time Lightroom is reasonably spry, I can make a fresh boot of Lightroom 5.6 sluggish after just a few minutes by doing the following:

Select an image. Make a virtual copy. Apply a color label. Repeat.

At first, this is no problem — no sluggishness, no delays — but within ten minutes things get slow to the point where if I apply the color label too quickly, it gets applied to the original image rather than to the virtual copy. I have to wait and watch for the blink — the little refresh which tells me that Lightroom has finished the make-virtual-copy task — before applying the color label. The longer I do this, the slower Lightroom gets, until before long the delay between making a virtual copy and when I can apply the label is counted in five to ten seconds.

I'm usually in the Develop module when I'm doing this, and other Develop functions remain responsive.
Photo of Steve Sprengel

Steve Sprengel, Champion

  • 2579 Posts
  • 323 Reply Likes
Mark,

Are we talking about 30 VCs or 100 or 1000?

What memory, virtual memory, or other resource usage difference do you see for LR or the entire system from when you start to when it starts to be slow, to when it takes seconds per VC.

Can you tell if the HD (SSD) is in use via a drive-light or task monitor?
Photo of Mark Thomas

Mark Thomas

  • 36 Posts
  • 1 Reply Like
I'd say between 30 and 100. I'll do an experiment tonight, keep count, and keep an eye on the disk activity.
Photo of Jim Wilde

Jim Wilde, Champion

  • 258 Posts
  • 74 Reply Likes
I've just tried that test, got up to 80 VCs with no discernible slow-down, at which point I stopped.
Photo of Mark Thomas

Mark Thomas

  • 36 Posts
  • 1 Reply Like
I just tried it myself in the Develop module (i.e. Lightroom was loading a lot of raw files one after the other). Things weren't perceptibly slower until about number 75, at which point I saw the first occurrence of the color label being applied to the original rather than to the virtual copy. From that point on this process got slower and slower, with the color label consistently being applied to the original unless I waited for the little refresh blink — which took longer and longer — to happen first.

I see brief disk activity for each operation, but nothing unusual, memory pressure was low, and Lightroom was only using 1.99 GB. "Swap Used" (née Page Outs?) was 10.0 MB, which I think was unchanged since my last restart.
Photo of David Perez

David Perez

  • 26 Posts
  • 2 Reply Likes
William, that's an interesting perception, and exactly the opposite of what I've always thought... My perception has always been that to get any kind of even marginal performance from LR you needed the absolute FASTEST CPU, memory, and lots of spinning platters - and a LOT of the fastest ones you could find. And even BEFORE they were "reasonably" priced, an SSD was being pushed to help with the extreme slowness.

I can see the next system having 2 SSDs - 1 for O/S and apps, 1 for catalog and MAYBE cache, and the fastest writing spinning platters for images. I haven't done the research, but I wonder if some form of RAID will be useful to improve write speed?
Photo of William Anderson

William Anderson

  • 35 Posts
  • 7 Reply Likes
David,
Most of what we read about SSDs is marketing-hype repeating results achieved under ideal, fresh out of the box conditions. The specs are usually something like 500MB/550MB read/write speeds. I have a fresh SanDisk SSD Extreme II 240GB and it does, in fact get that speed. That occurs only if I am reading and writing a SEQUENTIAL file of at least 512K in size. On the other hand, if I randomly write a file of 128K or less, the speed drops to 212MBs. If I randomly write a file of 4K or less the speed drops to 77MBs.
Than there the matter of control unit and system file contention. Unlike RAM, disk drives need to access data via a controller. In order to access data through a controller, you have to wait in a line, oddly enough called a queue. Typically when the queue length is 0 to 1, so not much waiting happens. However, in a really busy system, the queue can start to build. If it reaches 10 or more it can start the slow access times. This is especially true if you have both of your drives on a single controller, which is the typical layout. You can watch what your queue length does on the disk tab of the resource manager.
The other critical metric you can watch while in the file tab is the response time column. The response time is a measure of how quickly the disk responds to the request for data. Ideally, response time should be no more than 1ms.
System files can become bottlenecks because during certain activities, such as MFT and Bit Map update, the drive becomes locked to writes. That can drive up response time. For SSDs, every write has to be written to new locations, so continuous random writes can take their toll.
So, fire up the resource monitor, get to the file tab and watch what the response time column does and what the queue length is doing while you are running your LR session during the slow downs.
Bill
Photo of David Perez

David Perez

  • 26 Posts
  • 2 Reply Likes
Interesting, William. I'm going to have to watch some of that one of these days when I'm doing something that really impacts Lightroom.
Most recently, my biggest problem has been extremely slow creation of 1:1 previews. The desktop does them at a rate of somewhere around 16-19 per minute. The LAPTOP, on the other hand, is 2-3 per minute. Next time I'm doing a bunch I'll watch the monitor 'cause I've asked the question and it doesn't seem like the CPU and memory would be slow enough to cause this huge disparity.
Photo of Henrik Helmers

Henrik Helmers

  • 1 Post
  • 1 Reply Like
I just bought a brand new retina iMac, with maxed out specifications (4GHz i7, 32GB RAM, 689/704MB/s SSD). To my surprise, Lightroom still performs rather poorly. Throughput is just fine, but the interface still lag when I use it.

I tried Aperture, and it absolutely flies. As it's being discontinued I'm stuck with Lightroom.

Adobe, could you please get your stuff together? Pretty pretty please?
Photo of David Perez

David Perez

  • 26 Posts
  • 2 Reply Likes
I don't think you should hold your breath... What little impetus there formerly was for Adobe to improve performance, feature sets or customer support has been eradicated by the Creative Cloud. They now have a captive audience forced to pay a monthly fee with no foreseeable end in sight.

And the discontinuation of competition like Aperture (presuming this to be true) is another nail in the coffin of perpetual licensing and any requirement for Adobe to act in a competitive manner. With a multimillion dollar cash cow and the elimination of any semblance of knowledgeable customer support there is no longer anything to encourage Adobe to innovate or improve.
Photo of Alex Ismagilov

Alex Ismagilov

  • 3 Posts
  • 0 Reply Likes
Последний лайтрум это просто блядский тормоз какой-то!!!
На топовом железе (Core I7/16G RAM/ SSD + 1TB HDD for RAW) + все советы по оптимизации выполнены.
Вообще невозможно стало работать на нем быстро. Тормозит интерфейс безбожно.
ЧТО можно делать 10 секунд при простом увеличении файла 1:1 при том что превью заренее простроены???
Нет предела моему злу на этот продукт.

Пойду учить Capture One и больше не куплю ни одного апдейта этого лайтрума.
Photo of mary

mary

  • 36 Posts
  • 1 Reply Like
my trouble with lagging was cured when i replaced the SSD drive with a conventional one. I tried all the performance tricks found on lots of threads, but nothing worked until the drive itself was replaced. There was nothing wrong with the drive or with the installation, just an incompatibility they haven't ironed out yet.

my $10/mo subscription keeps my LR and PS updated for FAR less than it would cost for standalone. And i'm pleased overall with how Adobe responds to its customers, appreciating the fact that they can't possibly cover the multiplicity of configurations and needs of so many millions of users.
Photo of Dan Berdal

Dan Berdal

  • 34 Posts
  • 2 Reply Likes
you're saying that LR ran better once you removed the SSD? In what ways did your performance improve?
Photo of Robert Frost

Robert Frost

  • 392 Posts
  • 51 Reply Likes
I read Bill's suggestion that ssds could be the problem with their slow random writes, but when I replaced my ssd that has just the catalog and previews on it with a HDD with the same catalog and previews, it slowed down during rendering 1:1 previews, just as the ssd did.

Bob Frost
Photo of Ron Hu

Ron Hu

  • 45 Posts
  • 2 Reply Likes
When you change disks, Windows (if Windows) defaults to not ignoring FUA (Forced unit access) meaning write-throughs are not cached for the short term and written in the background. The system and application wait for the write IO to complete.

control-panel->device manager->disk drives (on left)->, Properties->Policies Tab.

Check box on the right most, bottom box "Turn off Windows write-cache buffer flushing...."

if that box is greyed out, then it is the disk and/or device driver (HBA driver) that is preventing it from being changed. Sometimes software RAID drivers are like this as they cannot take a power failure with data corruption and thus must keep the media on disk written vs. cached.

Ron
Photo of Molly Finch

Molly Finch

  • 2 Posts
  • 0 Reply Likes
While I use Lightroom it tends to flash rapidly. Can you give me an Idea of how to make it stop? If I had seizure it would through me into one.
Photo of Andrew Hoeveler

Andrew Hoeveler

  • 8 Posts
  • 0 Reply Likes
I have the same issue, mostly with the menu bar area (where the 'library' 'develop' 'map' 'book' etc text is)
I would recommend you go to preferences and turn OFF the GPU settings - don't let it use your GPU, and see if that helps. It definitely helped my whole UI from flashing and being super sluggish, but it didn't make that menu bar flashing thing go away!