Lightroom speed

Bebop said:
Have you tried changing the raw file cache size? (Under file handling in preferences). I vaguely remember being told to increase this from the default value to improve performance. Mine is currently set to 10GB - not sure what it was originally. Just a thought.
Click to expand...
Yep. I'm even running the config.lua hack to change core preference to 0.51 but that doesn't appear to help much either.
 
Try moving the catalogue to a freshly formatted filesystem (having deleted the previews directory tree first).
 
Denyerec said:
I've turned off every "advanced" feature LR has (Geo, face, GPU etc) to attempt to improve performance. Nothing helped. As I tag people at shoot time, the face recognition is a resource bleed I can do without.
Click to expand...

I've not had to do that.
Can you describe your workflow, the process you go through where you experience slowdown and I'll go through the same and see if I see the same. That could help point to either hardware or lightroom itself, or it may be you have a different workflow to me.

My catalogue has 124K photos in it, size is 1.26Gb as I said on a separate SSD drive. My preview cache is 43Gb, preview size is 1440 pixels, quality high, discard after 30 days. Face detection is turned off as I tend to run that on a set if required.
My raw cache is 20Gb, on the same ssd as the catalogue
I'm using my graphics processor - just a Geoforce GTX285, smart previews are turned off.
 
You can see everything in the videos I linked in the adobe thread, along with specs and further detail. Along with others with the same problem, others with no problem, etc etc ad nauseum. There's little point regurgitating it again here, especially as plenty of others have commented on the Adobe thread with additional input:

https://feedback.photoshop.com/photoshop_family/topics/lightroom-cc-2017-poor-performance

I've tried every tip, tweak and fiddle off the internet and it's still a sack of s***. Either it doesn't like D800 NEFs, it's conflicting with some other piece of software on my system (Though I reinstalled Windows as one strategy, and that failed), doesn't like the 2nd complete system rebuild I've done to try and improve performance (Different mobo, ram, cpu, ssds) or it doesn't like me. I'm outta ideas.
 
Ok, sorry I was trying to help rather than go through a rather long winded thread to pick up the details. Whilst there are people on there saying they have similar problems, there's also others saying they don't see issues.
Theres a comment of Nobody can build a computer fast enough to run LR. Yet I have and don't see issues!

Ok so;
I'm currently regenerating the 1:1 previews on the images in the video to see if the cache was corrupted or something. It's taken 2 hours so far, and it's at 58%. (700 images). In another 2 hours I will be able to say.

I have a 5D mk3. I'm running Lightroom 6.9 standalone with raw 9.9
I've selected 752 images taken at a wedding last week and regenerated the 1:1 previews in 11 minutes. I then selected 1257 images taken at a rugby tournament a couple of years ago (as my preview retention is set to 30 days) and these took just over 20 mins
Both times Lightroom peaked at about 65% cpu usage,
Zoomed out 100% on other sets in the library module and switching from picture to picture (as in your video) it builds the previews (loading) in about 2-3 secs depending on image, time after time.


upload_2017-8-20_7-58-19.png

SO C: is my OS on an 512Gb M2 Evo 950 SSD
D: is my 512Gb Evo 850 SSD for catalogue and cache. Overkill but whilst I was buying...
E: is my large raid
F: is my other Evo 850 SSD with this years raws on


I'd say it was hardware related but your spec looks good so I can understand your frustration. You say your spec is:
  • i7 4790k @ 4Ghz
  • 32Gb RAM
  • SSD Catalog
  • 2x HGST 5Tb RAID 1 image host drives
  • nVidia 970 GTX
  • 2560 x 1440 display, LR in Single Display mode only
  • Windows 10 Pro 64bit
Wheres the cache located and what size is it? Have you tried making it large and putting it on the SSD with the catalogue. What SSD is it?
 
Last edited:
Also remember to move the adobe Raw Cache off the C: drive. It doesn't follow the catalogue when you move that. A lot of it comes down to I/O bottlenecks I'm sure, no CPU or memory shortages would ever make a program as unresponsive as I've seen LR, but I can say it's improved a little as I've moved caches and catalogues off the C: drive (though still on the same sata SSD, even getting its own filesystem is a big benefit. Whilst my SSD is not current top spec it's not bad and the program still shouldn't get this slow..
 
Last edited:
Can't say I've ever been hampered by LR CC performance, even on my older i7-2600k/16gb/SSD.

Advise that stands for LR is that it loves a good CPU (preferably quad core) and fast cat and image disks. Where possible have your cat and at least your working set of images on a SSD. Only problem with those hybrid drives is that you have no real control over what is in the flash section until it decides it should be there.

Also turn off GPU acceleration, that seems to make things worse.
 
There's plenty of people with catalog and cache on SSD, and it is far from a golden bullet.
 
SSD is a no brainer, who wouldn't build a machine with performance in mind without one? That's been the norm for five years or more.
 
no doubt, but most will still only put OS and programs on it and have data on spinning media. or use one of the mediocre options such as the hybrid/fusion drive.

or of course they have a cheap machine that didnt have a flash option.
 
"data on spinning disk" can't go anywhere near explaining why the user interface gets bogged down so heavily when there's anything going on. Unless the UI rides on random reads across your entire library, and doesn't use asynchio..? If so, the designer wants shooting..

I am more inclined to think the issue is database engine and locking, or crappy thread management, or just bad UI decisions that require a lot of I/o to get even basic screens up.
 
Last edited:
drdocmatt said:
"data on spinning disk" can't go anywhere near explaining why the user interface gets bogged down so heavily when there's anything going on. Unless the UI rides on random reads across your entire library, and doesn't use asynchio..? If so, the designer wants shooting..

I am more inclined to think the issue is database engine and locking, or crappy thread management, or just bad UI decisions that require a lot of I/o to get even basic screens up.
Click to expand...


But as mentioned and shown, I don't see this. As above, I've repeated the tests with no significant depreciation from performance, so it's just a case of finding what the difference is between my system and ones with issues. Now I know mine was £2k in parts and was built specifically for my photography, but even on my older machine I didn't see the slow performance mentioned. 2 hours to 1:1 render 700 images when mine takes a fraction of that. I can't believe it's an OS issue, so it's got to be hardware or the way it's configured.
 
drdocmatt said:
"data on spinning disk" can't go anywhere near explaining why the user interface gets bogged down so heavily when there's anything going on. Unless the UI rides on random reads across your entire library, and doesn't use asynchio..? If so, the designer wants shooting..

I am more inclined to think the issue is database engine and locking, or crappy thread management, or just bad UI decisions that require a lot of I/o to get even basic screens up.
Click to expand...

Again.. I'm not saying SSD is a magic bullet. At the risk of repeating myself, the combination of good cpu and SSD will go a long way to making sure your system is performing to the best of its capabilities. Lightroom does do funny things with disk i/o, there's an old thread on here by a guy called arad85 who did a load of testing on the subject of lightroom and SSD.

And like Byker28i above, again my old 2600k system seems to work perfectly well with lr cc. But like I say again there are too many variables for it to suggest it'll work well on every system and editing situations.

They do need to fix the Gpu acceleration though, being faster switched off isn't really ideal.
 
GPU acceleration seems to bring make the image zoom more smoothly, that's about it.. :) Low end motherboards mean time taken to load the full resolution image into the GPU is increased, however, and I wonder if that's why a lot of people see slowdowns there. High end server class motherboards have twice as many memory channels per CPU socket and much higher PCIe bandwidth. On-board sata probably isn't the hottest chipsets in the world on cheaper systems too. That's one set of reasons why server/workstation class hardware costs 5x bog standard kit.

But even so, it's incredible how unresponsive LR can become, even if the chipset is half as fast, LR gets like treacle.
 
Byker28i said:
Ok, sorry I was trying to help rather than go through a rather long winded thread to pick up the details.
Click to expand...

My post (the first post) detailed everything - no digging required :) (Thought I'd save myself the hassle of retyping my diatribe!)

Byker28i said:
SO C: is my OS on an 512Gb M2 Evo 950 SSD
D: is my 512Gb Evo 850 SSD for catalogue and cache. Overkill but whilst I was buying...
E: is my large raid

Wheres the cache located and what size is it? Have you tried making it large and putting it on the SSD with the catalogue. What SSD is it?
Click to expand...

Almost uncanny, but my main system is a Samsung NVMe M2 SSD, (Cache is here) and the catalog is on a Corsair Force GS - both have more than adequate bandwidth to move RAW files at 10 per second so if it's disk limiting I'd be staggered. Cache is 50gb, and I don't use LR for any video work. RAWs are on a raid pair of HGST 5Tb's, but I've tried with the RAWs on the catalog and system SSDs too with no luck. Watching the disk throughput graphs whilst using the application indicates it's not disk limiting.
 
You must log in or register to reply here.
Back
Top