This issue collects information passed between myself and the Adobe care team on twitter, who as of April 21st recommended that I make a post here so that the development team could track it.
Starting off with the most up to date system info post:
https://pastebin.com/ngEf5L9y
The summary of the problem is basically laggy / insufferably slow performance issues with LR CC running on a system as follows:
I have been engaged with Adobe on this issue for several months, during which time I have kept my display drivers and lightroom up to date.
Performance *HAS* improved slightly since 6.10 but is still not at a point where it is comfortable to smoothly work. Every operation has a lag / UI update that just makes the whole experience jarring. The memory leak that would send LR to its knees was indeed resolved with 6.10, so performance no longer degrades as rapidly over time as it used to, however baseline performance is still not what I'd expect and is certainly not comfortable to work with. Editing in Lightroom is a headache to be dreaded right now, so much so that I've been putting off jobs that I really shouldn't be.
Video 1
Video 2
https://youtu.be/_e1xTbA3L94
I've produced another video that shows the GPU accel colour shift and screen blackout. This time LR had been open for a few hours, so it's the absolute worst case performance. Running on 6.8 / 6.9 as 6.10 had not yet been released
Video 3
https://www.youtube.com/watch?v=22LgfhKskJA&feature=youtu.be
Another video, this time with some diagnostic information onscreen. It's a long video as I was discussing with a reddit group ideas on how to improve performance. Skip through and you'll find CPU readouts, HDD benchmarks and some other stuff. This was recorded during a 1:1 preview generation session, which took 3 hours for 1000 images.
I've had lightroom open long enough to import 286 images and generate 1:1 previews for them. Performance is still just as bad as in the recorded videos. I'll leave it open and idling overnight to see if it leaks any memory, but honestly the concept of editing even this tiny set of ~300 images is enough to give me a headache.
Face tagging, geotagging, and all other extraneous gubbins turned off from day 1. 1:1 and Smart previews. 90% CPU over 4 cores, but no account given, seemingly, to people trying to use LR while an import is in progress. Its borderline unusable as it is (As I demonstrated in my videos) but during import - no chance. I normally leave it on overnight importing images, but this was a rush job. Rush. Hah.
At this point I was tempted to revert back to 5.7 as , although not exactly a greased sow in terms of performance, it is certainly less cumbersome than CC.
Starting off with the most up to date system info post:
https://pastebin.com/ngEf5L9y
The summary of the problem is basically laggy / insufferably slow performance issues with LR CC running on a system as follows:
- 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
I have been engaged with Adobe on this issue for several months, during which time I have kept my display drivers and lightroom up to date.
Performance *HAS* improved slightly since 6.10 but is still not at a point where it is comfortable to smoothly work. Every operation has a lag / UI update that just makes the whole experience jarring. The memory leak that would send LR to its knees was indeed resolved with 6.10, so performance no longer degrades as rapidly over time as it used to, however baseline performance is still not what I'd expect and is certainly not comfortable to work with. Editing in Lightroom is a headache to be dreaded right now, so much so that I've been putting off jobs that I really shouldn't be.
Video 1
https://www.youtube.com/watch?v=Ymh7o9H9wD4
This initial video opened up the dialog with Adobe, and was recorded on 6.8. This is the best performance I ever see from LR as it was freshly loaded up and hadn't been subject to the memory leak in versions < 6.10 . 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.
Video 2
https://youtu.be/_e1xTbA3L94
I've produced another video that shows the GPU accel colour shift and screen blackout. This time LR had been open for a few hours, so it's the absolute worst case performance. Running on 6.8 / 6.9 as 6.10 had not yet been released
Video 3
https://www.youtube.com/watch?v=22LgfhKskJA&feature=youtu.be
Another video, this time with some diagnostic information onscreen. It's a long video as I was discussing with a reddit group ideas on how to improve performance. Skip through and you'll find CPU readouts, HDD benchmarks and some other stuff. This was recorded during a 1:1 preview generation session, which took 3 hours for 1000 images.
I've had lightroom open long enough to import 286 images and generate 1:1 previews for them. Performance is still just as bad as in the recorded videos. I'll leave it open and idling overnight to see if it leaks any memory, but honestly the concept of editing even this tiny set of ~300 images is enough to give me a headache.
Face tagging, geotagging, and all other extraneous gubbins turned off from day 1. 1:1 and Smart previews. 90% CPU over 4 cores, but no account given, seemingly, to people trying to use LR while an import is in progress. Its borderline unusable as it is (As I demonstrated in my videos) but during import - no chance. I normally leave it on overnight importing images, but this was a rush job. Rush. Hah.
At this point I was tempted to revert back to 5.7 as , although not exactly a greased sow in terms of performance, it is certainly less cumbersome than CC.
Posted 2 years ago
Rikk Flohr, Official Rep
Melissa Rios, Lightroom Support Product Manager
Rikk Flohr, Official Rep
I edited the post title already so it is good.
The Slider/Brush behavior you describe is typically GPU related which is why I am asking. My home system is very similar to yours (I have the same video card and Ram) but I don't see these behaviors. (I have GPU enabled).
If you will indulge me for a test can you:
1. Create a new catalog for test purposes and import a few of your bigger (file size) images into the test catalog.
2. Turn off GPU in Preferences.
3. Restart your computer.
4. Launch Lightroom with the test catalog.
5. Attempt the Slider and Brush adjustments that have been plaguing you.
Are you seeing similar lags in this test environment? Differences?
The Slider/Brush behavior you describe is typically GPU related which is why I am asking. My home system is very similar to yours (I have the same video card and Ram) but I don't see these behaviors. (I have GPU enabled).
If you will indulge me for a test can you:
1. Create a new catalog for test purposes and import a few of your bigger (file size) images into the test catalog.
2. Turn off GPU in Preferences.
3. Restart your computer.
4. Launch Lightroom with the test catalog.
5. Attempt the Slider and Brush adjustments that have been plaguing you.
Are you seeing similar lags in this test environment? Differences?
Hey Rikk,
Apologies for the delay, real life has a nasty habit of kicking me in the teeth at the moment :/
I tested the new catalog as you suggested but see no performance improvement beyond initial LR loading speed (As you'd expect with a small catalog devoid of images and presets/preferences).
Performance is still very similar to my recorded videos, though without the impediment of the memory leak worsening things over time.
Are there any tools, perhaps something like Windows Performance Monitor or some such (I'm not a Win32 developer so my knowledge here is terrible) that could be attached to generate meaningful debug information to help with isolating the causes ?
Apologies for the delay, real life has a nasty habit of kicking me in the teeth at the moment :/
I tested the new catalog as you suggested but see no performance improvement beyond initial LR loading speed (As you'd expect with a small catalog devoid of images and presets/preferences).
Performance is still very similar to my recorded videos, though without the impediment of the memory leak worsening things over time.
Are there any tools, perhaps something like Windows Performance Monitor or some such (I'm not a Win32 developer so my knowledge here is terrible) that could be attached to generate meaningful debug information to help with isolating the causes ?
My gpu-support broke down after the latest update to 2015.10.
Lightroom crashes when in library mode and selecting a tiff-file and then switching to develop mode. Ticking off the gpu-support cures the problem. I have the newest gpu drivers and win10 (1703). Gpu is amd R9 380.
I'm tired of being a betatester. Previous version was the pretty good though (it didn't crash).
Lightroom crashes when in library mode and selecting a tiff-file and then switching to develop mode. Ticking off the gpu-support cures the problem. I have the newest gpu drivers and win10 (1703). Gpu is amd R9 380.
I'm tired of being a betatester. Previous version was the pretty good though (it didn't crash).
Rikk Flohr, Official Rep
@Denyer. Thanks for testing. I am still gathering data from the participants in this thread.
I have the same problem as Risto. I recently updated my AMD RX480 graphics drivers on Windows 10 and now I can't use the develop module without LR 2015.10 crashing. If I disable the GPU then everything works great.
Thanks, deselecting GPU acceleration resolved my slow Lightroom issue
Is storing your images on a RAID device supported? My disk is straight data disk and is connected via thunderbolt. I don't notice laggy performance.
Logical RAID drives appear as single volumes in Windows, I don't think LR would have any insight into what is/isn't a RAID device? As I (And I'm sure many others) require the redundancy in case of a drive failure, an incompatibility with RAID (Software and hardware) would be beguiling - especially as from a software level the disk(s) will appear as a single write target.
Could be wrong, but it'd be super unlikely - I can test it by plonking my latest shoot onto a single disk and then running the test that Rikk outlined above.
Could be wrong, but it'd be super unlikely - I can test it by plonking my latest shoot onto a single disk and then running the test that Rikk outlined above.
I am cutting my venes with Lr from version to version. Every (every!) version of Lr is slower / more laggy. Regarldless of hardware. Years ago I started with Lr 1.5 and I had 3 MP JPEG's - Yes 3MP , but on Celeron (Pentium 4 era) with 512 MB ram! I thought this is the best software on planet.
I started to curse Lr after version 4... I upgraded hadrware to have latest and gratest. 3 SSD's: images on one, 99GB !!! cache on another, catalog on third... I have SAME camera now for 3 years, still performance degardes. I it laggy EVEN if I go to edit thoose 3 MP files from 10 years ago. I have 2 computers with 6-core CPU, (one have HDD's and 16 GB ram, and older GPU, other have 32GB and SSD's and newer GPU), but no difference on them regarding Lr.
Sometimes (?!?) for some projects it works better, another day it is to pull hair slow. I started to use smart previews. The day I changed that setting it was FAST... ok, at least workable. But another day, same as before. Than GPU... when I enable it, Lr works better and CPU cooler is quiet, so GPU works. But Brushes are insane than. If unticked, brushes are more alive but Lr is a bit slower. I hear CPU cooler... with latest update, if I select / change 2-3 images fast one after another, the CPU works a lot, but it seems only few threads, since CPU get hot (cooler wakes) and Lr is almost unresponsive until image "loads" 100%, but only few cores out of 12 of my CPU is utilised. BTW making 1:1 previews upfront does nothing to performance.
Lr on that beast machine is almost no faster than on my 5 year old laptop with 8 GB of ram. Making new catalog for project does nothing. While exporting there is the only time whine CPU goes 100% with all 12 cores and export is VERY fast on my fastest machine and not so on slow laptop.
Photoshop have no issues, CorelDRAW/PAINT no issues and Capture One works smooth as butter. Only LR is hessitating SNAIL. Another aspect of bloated Adobe software code is Primiere, which is similar on performance and I started to thinking of harakiri. But than latest version after patches gived me hope, as I work now OK. Even I say "OK" (25 years on NLE's all from Avid, etc). So Lr need to be revamped. This is insane. We do not need ever new functions that bloats basic functions such are brushes, crop, etc... not to mention perspective correction.
I started to curse Lr after version 4... I upgraded hadrware to have latest and gratest. 3 SSD's: images on one, 99GB !!! cache on another, catalog on third... I have SAME camera now for 3 years, still performance degardes. I it laggy EVEN if I go to edit thoose 3 MP files from 10 years ago. I have 2 computers with 6-core CPU, (one have HDD's and 16 GB ram, and older GPU, other have 32GB and SSD's and newer GPU), but no difference on them regarding Lr.
Sometimes (?!?) for some projects it works better, another day it is to pull hair slow. I started to use smart previews. The day I changed that setting it was FAST... ok, at least workable. But another day, same as before. Than GPU... when I enable it, Lr works better and CPU cooler is quiet, so GPU works. But Brushes are insane than. If unticked, brushes are more alive but Lr is a bit slower. I hear CPU cooler... with latest update, if I select / change 2-3 images fast one after another, the CPU works a lot, but it seems only few threads, since CPU get hot (cooler wakes) and Lr is almost unresponsive until image "loads" 100%, but only few cores out of 12 of my CPU is utilised. BTW making 1:1 previews upfront does nothing to performance.
Lr on that beast machine is almost no faster than on my 5 year old laptop with 8 GB of ram. Making new catalog for project does nothing. While exporting there is the only time whine CPU goes 100% with all 12 cores and export is VERY fast on my fastest machine and not so on slow laptop.
Photoshop have no issues, CorelDRAW/PAINT no issues and Capture One works smooth as butter. Only LR is hessitating SNAIL. Another aspect of bloated Adobe software code is Primiere, which is similar on performance and I started to thinking of harakiri. But than latest version after patches gived me hope, as I work now OK. Even I say "OK" (25 years on NLE's all from Avid, etc). So Lr need to be revamped. This is insane. We do not need ever new functions that bloats basic functions such are brushes, crop, etc... not to mention perspective correction.
Sorry for all spells... I can not edit the comment anymoore.
What's most surprising about all of this is that Adobe seem to want to make it look as though this is some sort of specific issue?
This is a universally known problem. Nobody can build a computer fast enough to run LR.
I was in the same boat. Always loved LR and most Adobe software, but over the last year I canceled my subscription and stopped editing.
I won't start again until this is resolved for the vast majority of users.
Everywhere I look people with outrageously expensive computers can barely run LR (I am one of those people) and I will not post log files and pretend this is a support issue.
This is a general problem and must be addressed somehow. It has to be possible, because LR used to run better.
Though it hasn't run _well_ for years. It should feel like Photoshop. But it doesn't.
This is a universally known problem. Nobody can build a computer fast enough to run LR.
I was in the same boat. Always loved LR and most Adobe software, but over the last year I canceled my subscription and stopped editing.
I won't start again until this is resolved for the vast majority of users.
Everywhere I look people with outrageously expensive computers can barely run LR (I am one of those people) and I will not post log files and pretend this is a support issue.
This is a general problem and must be addressed somehow. It has to be possible, because LR used to run better.
Though it hasn't run _well_ for years. It should feel like Photoshop. But it doesn't.
Rikk Flohr, Official Rep
Adrian,
I would love to have system information from you as well. I would love to get to the bottom of this issue.
I would love to have system information from you as well. I would love to get to the bottom of this issue.
Just system specs? Core i7 920, 32gb ram, win 10 x64, Samsung 950 SSD...
But again, I can also run it on a Core 2 Duo laptop with a mechanical HDD and 4gb of ram and it barely makes a difference :(
Even the difference between 8mp all the way to 42mp raws is not very noticeable.
The biggest difference stems from displaying LR on a 1080p vs 4k monitor (perhaps an obvious statement considering how much more processing will be involved in that)
I have stored the catalogue and pictures on dedicated SSDs and normal HDDs with no real difference in performance either.
But again, I can also run it on a Core 2 Duo laptop with a mechanical HDD and 4gb of ram and it barely makes a difference :(
Even the difference between 8mp all the way to 42mp raws is not very noticeable.
The biggest difference stems from displaying LR on a 1080p vs 4k monitor (perhaps an obvious statement considering how much more processing will be involved in that)
I have stored the catalogue and pictures on dedicated SSDs and normal HDDs with no real difference in performance either.
Rikk Flohr, Official Rep
Thank you.
I agree with Tom. I realize Rikk that you need specific information to identify the problem but at the same time, Lightroom is simply notorious for massive slowdowns. On the other hand, it has fantastic functionality which is why so many of us keep using it despite the slowdowns. Honestly I expected to have to switch to Photoshop by now but I find that I keep learning about additional functions in Lightroom that cover my needs.
And I do want to thank you Rikk for taking a serious interest in the problems.
There is a lot of speculation that Lightroom only uses one core on multi-core machines. Perhaps you would investigate this? Do the Apple and Microsoft API's make it easy or hard to program to use multiple cores?
Next time I have a massive slowdown in editing I will video it on my iPhone and send it to you along with all the system configuration information I can think of.
In the meantime, please note carefully that I personally experience slowdowns in two specific situations:
A. Scrolling through RAW photographs in G mode when I have not previously created 1-1 previews. Some people in dpreview forums have speculated that Lightroom is not taking advantage of the JPEG's embedded in the RAW files. This of course would only be helpful until one begins to edit the files in Lightroom, ..... but I usually only scroll through ALL the photographs in a shoot initially to do ranking, prior to any edits at all. I bet that is a common workflow.
Seems like this could be corrected. Would you please check this out?
This particular problem is so well known (slow scrolling of RAW files) that some firms have developed products just to deal with it, such as FastRawViewer or Photo Mechanic.
Creating 1-1 previews solves the scrolling problem (until I have do some edits) but that itself is a slow process that uses a lot of hard disk. For this reason I usually do NOT create 1-1 previews until I have done the initial culling of my shoot.
B. Here is the big one: after I have done some edits, maybe 10 to 20 edits, to a photograph, further editing slows down a LOT. I do use the brush for dodge and burn quite a bit as well as the clone/heal function. That should be a clue.
It feels as if Lightroom is recreating the entire image from scratch from history every time I do an additional clone/heal or brush. Crazy. There might be something extraordinarily inefficient about the way that process is programmed. I can't help but think that there is an algorithmic fix possible here. Would you please check this out?
Another clue is that to my best recollection, speed problems escalated dramatically with the transition from v5.7 to 6.x and CC. Can you check out whether something fundamental changed there?
System: As I mentioned earlier, I keep 100gig open on my SSD, I have a 2015 MacBook Pro I7 with 16gig, I bumped the cache to around 30gig, and I seem to experience similar problems whether I have GPU turned on or off. I do keep several had drives attached to my computer as backup drives. I edit with an external monitor that is 4k 24" run in 2k mode. My MacBook Pro is rated to drive this monitor just fine and it does.
Finally, I have noticed that closing all internet browsers speeds up Lightroom a bit. I find that open browser pages use a lot of CPU even when they are doing "nothing". Something is afoot with the advertisers doing work in the background, I suspect. Sigh. So I do encourage Lightroom users to keep browsers closed where possible.
Thanks very much for your assistance Rikk.
And I do want to thank you Rikk for taking a serious interest in the problems.
There is a lot of speculation that Lightroom only uses one core on multi-core machines. Perhaps you would investigate this? Do the Apple and Microsoft API's make it easy or hard to program to use multiple cores?
Next time I have a massive slowdown in editing I will video it on my iPhone and send it to you along with all the system configuration information I can think of.
In the meantime, please note carefully that I personally experience slowdowns in two specific situations:
A. Scrolling through RAW photographs in G mode when I have not previously created 1-1 previews. Some people in dpreview forums have speculated that Lightroom is not taking advantage of the JPEG's embedded in the RAW files. This of course would only be helpful until one begins to edit the files in Lightroom, ..... but I usually only scroll through ALL the photographs in a shoot initially to do ranking, prior to any edits at all. I bet that is a common workflow.
Seems like this could be corrected. Would you please check this out?
This particular problem is so well known (slow scrolling of RAW files) that some firms have developed products just to deal with it, such as FastRawViewer or Photo Mechanic.
Creating 1-1 previews solves the scrolling problem (until I have do some edits) but that itself is a slow process that uses a lot of hard disk. For this reason I usually do NOT create 1-1 previews until I have done the initial culling of my shoot.
B. Here is the big one: after I have done some edits, maybe 10 to 20 edits, to a photograph, further editing slows down a LOT. I do use the brush for dodge and burn quite a bit as well as the clone/heal function. That should be a clue.
It feels as if Lightroom is recreating the entire image from scratch from history every time I do an additional clone/heal or brush. Crazy. There might be something extraordinarily inefficient about the way that process is programmed. I can't help but think that there is an algorithmic fix possible here. Would you please check this out?
Another clue is that to my best recollection, speed problems escalated dramatically with the transition from v5.7 to 6.x and CC. Can you check out whether something fundamental changed there?
System: As I mentioned earlier, I keep 100gig open on my SSD, I have a 2015 MacBook Pro I7 with 16gig, I bumped the cache to around 30gig, and I seem to experience similar problems whether I have GPU turned on or off. I do keep several had drives attached to my computer as backup drives. I edit with an external monitor that is 4k 24" run in 2k mode. My MacBook Pro is rated to drive this monitor just fine and it does.
Finally, I have noticed that closing all internet browsers speeds up Lightroom a bit. I find that open browser pages use a lot of CPU even when they are doing "nothing". Something is afoot with the advertisers doing work in the background, I suspect. Sigh. So I do encourage Lightroom users to keep browsers closed where possible.
Thanks very much for your assistance Rikk.
There are a LOT of people with performance issues (More than I know than without) but there are some people out there who don't have performance problems and can work quite happily with the software.
Either they are far, far more tolerant then we, or there is something system specific afoot. That said, I've built 2 computers for Lightroom so far, and both have sucked, so the problem is at least quite widespread, or my luck is just terrible :D
(Or there is some seemingly innocuous piece of software that I absentmindedly install every time (like the Wacom drivers or Crashplan) that ruins LR's performance somehow?)
Either they are far, far more tolerant then we, or there is something system specific afoot. That said, I've built 2 computers for Lightroom so far, and both have sucked, so the problem is at least quite widespread, or my luck is just terrible :D
(Or there is some seemingly innocuous piece of software that I absentmindedly install every time (like the Wacom drivers or Crashplan) that ruins LR's performance somehow?)
True! Saddly.
I use Lr, Pr, Au and Dw for at least 10 years. For all mentioned hold true that they perform progressively slower from version to version (not much, but noticable) and MUCH (MUCH!!) slower than their first versions (which was bought from other developers). The only Premiere blessed me with major speed improvement in CC2017.1 compared to CC2015.x.
I use other packages like Ps only from 2013 after CC enabled me to have them all. And Ps is only package that perform good in every version.
My system was installed 14.8.2015 - only hardware changes during that time was 16-32 GB ram and I regularly update SSD's here and there. On the same system I have currently installed 4 versions of Premiere: CS6 (for Encore), CC"2013" (for third party plugin that I use a lot), CC2015 (used to be main editor), CC2017.1 (is main editor now since "0.1" update).
- CS6 was perfect.
- CC was the same fast and stable, just few things changed that annoys me.
- CC2014 introduced UGLY GUI... refused to use it...
- CC2015 a bit toned down blue color and added few interesting features. After a good year or so, I stzarted to use it. It was REALLY stable version, but obviously under the hood updates ruined performance since it was slower and slower when using LUT's especially. So bad I wanted to make suicide (not joke) when I had deadline with huge lawsuit behind if I do not deliver. And Premiere wanted 10 seconds to refresh screen for every cut, slide, change... and sometimes 5 minutes to draw initial screen of timeline. In a desperation I tried CC2017 again, which I refused to use due to the most crashing Adobe package ever (crashed almost every time a mouse was moved). I rather never update Adobe software anymoore so "updates" are blinking in my CC note area. I clicked update for CC2017 and tried it. I opened same project that did not open under 10 minutes in CC2015. After conversion I was shocked! Is that possible? Opened instantly, no LAG what so ever... And this is converted project from CC2015. Wow... let it crash every minute I said... I have dedicated SAVE key on my custom keyboard anyway (because Adobe). But hey... it only crashed 2-3 times during workday. Yes with CC2015 I do not remember it's last crash, so much I forgot to save... now I'm saving again, but CC2017 on same old Windows, works great, where CC2015 is a nightmare... nothing changed.
I hope some LR version will bless me with major speed increase as Premiere did... until than, slight improvement is not worth speaking. We need 400% improvement.
I tested old JPEGS. My fisr digital camera have 1024*768 files. Thoose files work fast! 5MP RAF, 9MP RAF, 12MP JPEGS, 16MP DNG (out of Pentax), all work similarly slow. If system is "rested", it loads image in 2 seconds. "loads" is where detailed image is processed, not when low res thumbnail is shown. After system is "tired" (working on 100 files for a while jumping back and forth adjusting smlla changes here and there, tweaking...), it could load 3-5 seconds per image.
I do use "smartpreviews" as proposed a while ago for speed increment. That was good only for the time I swithed... That day LR was pleasure. Not blazing fast, but no lag. Only thast day! I do not understand.
PS: I will test SMARTPREVIEWS vs. NORMAL
I use Lr, Pr, Au and Dw for at least 10 years. For all mentioned hold true that they perform progressively slower from version to version (not much, but noticable) and MUCH (MUCH!!) slower than their first versions (which was bought from other developers). The only Premiere blessed me with major speed improvement in CC2017.1 compared to CC2015.x.
I use other packages like Ps only from 2013 after CC enabled me to have them all. And Ps is only package that perform good in every version.
My system was installed 14.8.2015 - only hardware changes during that time was 16-32 GB ram and I regularly update SSD's here and there. On the same system I have currently installed 4 versions of Premiere: CS6 (for Encore), CC"2013" (for third party plugin that I use a lot), CC2015 (used to be main editor), CC2017.1 (is main editor now since "0.1" update).
- CS6 was perfect.
- CC was the same fast and stable, just few things changed that annoys me.
- CC2014 introduced UGLY GUI... refused to use it...
- CC2015 a bit toned down blue color and added few interesting features. After a good year or so, I stzarted to use it. It was REALLY stable version, but obviously under the hood updates ruined performance since it was slower and slower when using LUT's especially. So bad I wanted to make suicide (not joke) when I had deadline with huge lawsuit behind if I do not deliver. And Premiere wanted 10 seconds to refresh screen for every cut, slide, change... and sometimes 5 minutes to draw initial screen of timeline. In a desperation I tried CC2017 again, which I refused to use due to the most crashing Adobe package ever (crashed almost every time a mouse was moved). I rather never update Adobe software anymoore so "updates" are blinking in my CC note area. I clicked update for CC2017 and tried it. I opened same project that did not open under 10 minutes in CC2015. After conversion I was shocked! Is that possible? Opened instantly, no LAG what so ever... And this is converted project from CC2015. Wow... let it crash every minute I said... I have dedicated SAVE key on my custom keyboard anyway (because Adobe). But hey... it only crashed 2-3 times during workday. Yes with CC2015 I do not remember it's last crash, so much I forgot to save... now I'm saving again, but CC2017 on same old Windows, works great, where CC2015 is a nightmare... nothing changed.
I hope some LR version will bless me with major speed increase as Premiere did... until than, slight improvement is not worth speaking. We need 400% improvement.
I tested old JPEGS. My fisr digital camera have 1024*768 files. Thoose files work fast! 5MP RAF, 9MP RAF, 12MP JPEGS, 16MP DNG (out of Pentax), all work similarly slow. If system is "rested", it loads image in 2 seconds. "loads" is where detailed image is processed, not when low res thumbnail is shown. After system is "tired" (working on 100 files for a while jumping back and forth adjusting smlla changes here and there, tweaking...), it could load 3-5 seconds per image.
I do use "smartpreviews" as proposed a while ago for speed increment. That was good only for the time I swithed... That day LR was pleasure. Not blazing fast, but no lag. Only thast day! I do not understand.
PS: I will test SMARTPREVIEWS vs. NORMAL
Im afraid Im in the same boat. I can't afford the time this is costing me so I am exploring some of the other catalog/editors out there.
Rikk Flohr, Official Rep
For those of you on this thread who are using Windows-based systems who has completely uninstalled their graphics drivers (not just updated) and then reinstalled from your manufacturer's latest version?
I was working from a completely clean (Non-upgrade) installation of windows 10 if that counts? I have always had GPU Acceleration disabled due to the strange colour shifting and display behaviours it caused.
(A segue I admit - but does anyone benefit from GPU Accel? Every thread I read says to turn it off, makes me wonder! :) )
(A segue I admit - but does anyone benefit from GPU Accel? Every thread I read says to turn it off, makes me wonder! :) )
Victoria Bampton - Lightroom Queen, Champion
> does anyone benefit from GPU Accel?
Yes - the specific people it was designed for - those running 4K and 5K monitors. Even then, there are downsides to consider (brushes are slower) but it makes Lightroom useable on those high res screens. Most people with standard res screens are better with it turned off.
Yes - the specific people it was designed for - those running 4K and 5K monitors. Even then, there are downsides to consider (brushes are slower) but it makes Lightroom useable on those high res screens. Most people with standard res screens are better with it turned off.
It looks like I did a complete uninstall / reinstall back in December (for other reasons -- nothing LR related). I was running 2015.4 at that time, and wasn't having any problems before the uninstall (and haven't had any problems with that version since). All issues are on the > 2015.4 updates.
Rikk Flohr, Official Rep
@Denyer EC - that doesn't count. I am looking to see if anyone has completely uninstalled their drivers and reinstalled from scratch after an OS installation.
Ahh OK, that's easily done for you, I can sort that out now if you'd like?
Would you recommend using the nVidia "Driver Cleaner", or do you suggest simply removing them via Add/Remove Programs in Control Panel?
Would you recommend using the nVidia "Driver Cleaner", or do you suggest simply removing them via Add/Remove Programs in Control Panel?
Rikk Flohr, Official Rep
At this point, I am just curious. We had a report from a user in the Adobe User to User forum who had similar performance issues. They ran diagnostics on their machine and found 2D video operations were lagging badly. An uninstall of the video software and reinstall restored functionality.
If you are comfortable with the process, it is worth trying.
I was just trying to gauge if any of those reporting performance issues had attempted this to get more data points.
https://forums.adobe.com/thread/2307390
If you are comfortable with the process, it is worth trying.
I was just trying to gauge if any of those reporting performance issues had attempted this to get more data points.
https://forums.adobe.com/thread/2307390
(Edited)
At this point I'd happily start drawing pentagrams on the floor with salt, so I'll give it a go and report back.
Rikk Flohr, Official Rep
I won't guarantee pentagrams are unlikely to help but I strongly suspect they are. Let me know what you find. Also, an engineer should be in contact with your shortly via email. Is the email on your account here valid?
Yes, email here is fine - thanks for letting me know as the spam filtering can be quite aggressive.
I had an Adobe rep do this for me during a help session. It didn't have any effect.
NVIDIA Quadro K1100M
NVIDIA Quadro K1100M
Hey Rikk, just jumping in to say that I did a complete uninstall of everything NVidia and reinstalled but it's still as bad. Are we seeing an NVidia trend here? Windows 10 here too and similar spec to the others. Lightroom CC, NVidia 1060, 16GB Ram etc
I did too, no joy.
So SMART vs REGULAR previews:
I use 2 monitors. On second monitor I have 1:1 preview selected. So I can see when image is rendered to highest resolution. It takes some time.
1) discarded smartpreviews and 1:1 previews. No image in folder selected. All images are 16MP DNG (Pentax), and already edited. All have with same preset applyd, but some with aditional brushes, radial filters and spot healing and perspective correction.
First 6-7 images needed exactly 5 seconds to be fully rendered after clicked on it. Than it was close to 6 for every image after that. Thoose with selective effects needed 8-12 seconds. I found out that perspective does not take much, most peformance hit is with brush and radial. Spot healing is slow to operate, but renders fast. What I found is that sometimes image on second monitor renders seconds after it is rendered on main window and sliders come back. Sometimes image renders much faster and sliders needs 10 seconds to show (sliders are gray during image loading).
This is not usable. If I need to load 250 images (average shootout) that is 30 minutes just to open them once. Multiply that with 10 per image during workflow that damn thing I'm paying regularly and not that little (e.g. Lr) takes me 5 hours of WAITING on average job. That means I loose 5*20 EUR (my low hourly rate) = 100 EUR / job. Thank you Adobe! I must charge more on already compating market or I just buy competition licence. Unfortunately, not using Lr does not save my bill, sicne I use Premiere which thankfully works (until next update).
2) Build 1:1 previews (in the prefferences "use smart previews" is unticked):
Images loads mostly instantly, some of them needs 1-2 seconds to render. So this is what I need. But I only tested 20 images. That means nothing since I did not test to work several hours. While image loads instantly, sliders still needs to "load": That is probably to render effects. Still this is much faster than using no previews. It takes 2-4 seconds to load sliders in develop mode.
3) Discard 1:1 previews and Build smart previews (in the prefferences "use smart previews" is ticked):
Some of images loads instantly. Most of them renders (loads) for about 2x the time as with 1:1 previews. Processor works much harders as my 1KG cooler starts to spin when working with smart previews, but is quiet with 1:1. Than another issue: Screen blackouts - some parts of tool panes blacks out. And approaching to next images demands several clicks until it goes. Even after image is rendered fully, it refuses to approach to next image and CPU cooler goes like mad. When cooler calms dow, the next image is loaded.
Interesting that sliders loads at about 1/2 the time as with 1:1 previews.
Cocnlusion: I will stop using Smartprevirews since it ruins performence, not improves it. Image loads quicker under 1:1 since it is prerendered. SmartPreview probably tryes to render 1:1 on the fly. It is even slower or similar than no previews at all. But sliders loads faster in Develop mode since effects are rendered at lower resolution file. (I guess).
Let's try the performance when tweaking the images.
The most annoying is perspective tool. The nods jumps all over so it is pain to adjust it right. Furthermore they stick to mouse and even you placed them and released mouse button it is dragged by moving mouse to somewhere out of screen. Same happens sometimes in brush editor (if GPU is selected, for shure).
Another annoyance is that on second monitor mouse click enlarges the image to 2:1, only than it is rendered to 1:1 as selected. And another click does not revert image back to FIT, but "fit" icon must be clicked, or another image selected, than it releasess it and revert it to fit.
Third annoyance (long ago noticed) is masking or brushing while having image at 100%. It is fine, until you want to move it (with hand tool, pressing spacebar), or zooming (in/out) while on brush or other selective tool. Once or twice it will do with much lag, but after few inteventions it will cease alltogether. You need to close the tool, wait until system rests, than open tool, select nod, and try again...
All in all: We pay big money to Adobe, and get this kind of software. Uggh. Sometimes I wish I would digg trenches for living, because there every shovel of dirt you lift, it is one less in the trench and you can see the progress. With Adobe software (mostly) you can see only suffer and little progress / joy. Sorry folks, that is how I (we?) see it after 10+ years with ever the same problems. New version will supposedly be better right.
Lets' try to edit some NEW previously unedited images:
Same crappy sluggish performance. Yes 1:1 previews loads image faster, but editing is a bit slower. Even paning image at 100% is laggy (1-2 seconds to move, if it moves in first attemtp) and zooming on an image still takes long. Using smartpreviews editing is a bit faster but you loose insight of image quality (sometimes I even reject image, which is fine otherwise), and image loading is double the time. So I guess I will NOT use smartpreviews from this test on. In fact...
FINAL CONSLUSION:
I will not use Lightroom until this is sorted out and Adobe release new version with some "mercury playback engine" which will clain REAL TIME EDITING again.
I'm sick of wasting my life on this forums, where we chase our tails debugging something for which we pay ADOBE to do it for us. We bought tool, not opportunity to debug one ourselves. We need something that works. Something that competition already have.
I reckon Adobe gives a *** if I leave. I will still pay for compete CC for other software (that I mostly curse as I do Lr). And even if I leave completely... huge stream of new customers comes in. Lightroom is amateurish software. It is great if you only open image, apply preset, press auto upright, auto lens corection and export (to social media from Lr directly). Thoose people are slow for masking by themselves or they do not mask competelly, so they do not know it is slow. They are attracted to make panoramas, HDR's, "books", and "slideshows", use (ugly) dehaze tool ...
We need speed.
Maybe I will make comparison video of editing 20 images using Lr and other tools.
I use 2 monitors. On second monitor I have 1:1 preview selected. So I can see when image is rendered to highest resolution. It takes some time.
1) discarded smartpreviews and 1:1 previews. No image in folder selected. All images are 16MP DNG (Pentax), and already edited. All have with same preset applyd, but some with aditional brushes, radial filters and spot healing and perspective correction.
First 6-7 images needed exactly 5 seconds to be fully rendered after clicked on it. Than it was close to 6 for every image after that. Thoose with selective effects needed 8-12 seconds. I found out that perspective does not take much, most peformance hit is with brush and radial. Spot healing is slow to operate, but renders fast. What I found is that sometimes image on second monitor renders seconds after it is rendered on main window and sliders come back. Sometimes image renders much faster and sliders needs 10 seconds to show (sliders are gray during image loading).
This is not usable. If I need to load 250 images (average shootout) that is 30 minutes just to open them once. Multiply that with 10 per image during workflow that damn thing I'm paying regularly and not that little (e.g. Lr) takes me 5 hours of WAITING on average job. That means I loose 5*20 EUR (my low hourly rate) = 100 EUR / job. Thank you Adobe! I must charge more on already compating market or I just buy competition licence. Unfortunately, not using Lr does not save my bill, sicne I use Premiere which thankfully works (until next update).
2) Build 1:1 previews (in the prefferences "use smart previews" is unticked):
Images loads mostly instantly, some of them needs 1-2 seconds to render. So this is what I need. But I only tested 20 images. That means nothing since I did not test to work several hours. While image loads instantly, sliders still needs to "load": That is probably to render effects. Still this is much faster than using no previews. It takes 2-4 seconds to load sliders in develop mode.
3) Discard 1:1 previews and Build smart previews (in the prefferences "use smart previews" is ticked):
Some of images loads instantly. Most of them renders (loads) for about 2x the time as with 1:1 previews. Processor works much harders as my 1KG cooler starts to spin when working with smart previews, but is quiet with 1:1. Than another issue: Screen blackouts - some parts of tool panes blacks out. And approaching to next images demands several clicks until it goes. Even after image is rendered fully, it refuses to approach to next image and CPU cooler goes like mad. When cooler calms dow, the next image is loaded.
Interesting that sliders loads at about 1/2 the time as with 1:1 previews.
Cocnlusion: I will stop using Smartprevirews since it ruins performence, not improves it. Image loads quicker under 1:1 since it is prerendered. SmartPreview probably tryes to render 1:1 on the fly. It is even slower or similar than no previews at all. But sliders loads faster in Develop mode since effects are rendered at lower resolution file. (I guess).
Let's try the performance when tweaking the images.
The most annoying is perspective tool. The nods jumps all over so it is pain to adjust it right. Furthermore they stick to mouse and even you placed them and released mouse button it is dragged by moving mouse to somewhere out of screen. Same happens sometimes in brush editor (if GPU is selected, for shure).
Another annoyance is that on second monitor mouse click enlarges the image to 2:1, only than it is rendered to 1:1 as selected. And another click does not revert image back to FIT, but "fit" icon must be clicked, or another image selected, than it releasess it and revert it to fit.
Third annoyance (long ago noticed) is masking or brushing while having image at 100%. It is fine, until you want to move it (with hand tool, pressing spacebar), or zooming (in/out) while on brush or other selective tool. Once or twice it will do with much lag, but after few inteventions it will cease alltogether. You need to close the tool, wait until system rests, than open tool, select nod, and try again...
All in all: We pay big money to Adobe, and get this kind of software. Uggh. Sometimes I wish I would digg trenches for living, because there every shovel of dirt you lift, it is one less in the trench and you can see the progress. With Adobe software (mostly) you can see only suffer and little progress / joy. Sorry folks, that is how I (we?) see it after 10+ years with ever the same problems. New version will supposedly be better right.
Lets' try to edit some NEW previously unedited images:
Same crappy sluggish performance. Yes 1:1 previews loads image faster, but editing is a bit slower. Even paning image at 100% is laggy (1-2 seconds to move, if it moves in first attemtp) and zooming on an image still takes long. Using smartpreviews editing is a bit faster but you loose insight of image quality (sometimes I even reject image, which is fine otherwise), and image loading is double the time. So I guess I will NOT use smartpreviews from this test on. In fact...
FINAL CONSLUSION:
I will not use Lightroom until this is sorted out and Adobe release new version with some "mercury playback engine" which will clain REAL TIME EDITING again.
I'm sick of wasting my life on this forums, where we chase our tails debugging something for which we pay ADOBE to do it for us. We bought tool, not opportunity to debug one ourselves. We need something that works. Something that competition already have.
I reckon Adobe gives a *** if I leave. I will still pay for compete CC for other software (that I mostly curse as I do Lr). And even if I leave completely... huge stream of new customers comes in. Lightroom is amateurish software. It is great if you only open image, apply preset, press auto upright, auto lens corection and export (to social media from Lr directly). Thoose people are slow for masking by themselves or they do not mask competelly, so they do not know it is slow. They are attracted to make panoramas, HDR's, "books", and "slideshows", use (ugly) dehaze tool ...
We need speed.
Maybe I will make comparison video of editing 20 images using Lr and other tools.
You and I seem to have similar experiences with speed and frustration, though in a conversation I had on twitter with Melissa, it at least felt like they are starting to take things seriously - hey, if they don't, we leave right? (Oh, you have tried the metadata tools in Capture One, haven't you? Ye gods.)
I found that using OBS Studio to screen-capture lightroom was the easiest way to relate performance to the tech staff, once people see just how paintful it is to use on your system it becomes very hard to ignore, but times and numbers are somehow abstract to process.
Also in agreement, is that if it takes 6 seconds to change between images and I have 1500 images to work through, that's 2.5 HOURS of time wasted just waiting for slow software. That's billable time, and it's really hurting my margins :(
I found that using OBS Studio to screen-capture lightroom was the easiest way to relate performance to the tech staff, once people see just how paintful it is to use on your system it becomes very hard to ignore, but times and numbers are somehow abstract to process.
Also in agreement, is that if it takes 6 seconds to change between images and I have 1500 images to work through, that's 2.5 HOURS of time wasted just waiting for slow software. That's billable time, and it's really hurting my margins :(
You two said it perfectly. This is the crux of it. The second there is any viable Adobe competition, I will go with that. Until then, I will not use any Adobe software anyway.
So the only way to get me back will be performance improvements.
I am not getting my hopes up. Thank god I don't need to use this stuff professionally.
So the only way to get me back will be performance improvements.
I am not getting my hopes up. Thank god I don't need to use this stuff professionally.
Rikk Flohr, Official Rep
Thank you to you all for contributing your experiences to this thread. Engineering is taking a look at the issues presented here and may be contacting some of you directly via email with more questions.
Happy to do whatever I can to help. Would love to see it fixed.
I also have had issues with performance. 16GB RAM on a 2012 MBP. I've gone so far are to start using CaptureOne. My photos are kept on a RAID 5 box over thunderbolt, the drive is plenty fast.
(Edited)
How do you like Capture One? Do you find that it does everything you were used to in Lightroom?
I use Capture One for tethering. Fantastic. I took courses on editing with Capture One and learned that C1 has superior color manipulation but I was not able to confirm that it has everything I use frequently in Lightroom such as radial or graduated filter. I stopped the editing experiment with C1 at that point. Also I wondered whether C1 could replace Photoshop but it is limited to 16 layers. I may try again at some point.
What I like in Capture One:
- no performance issues - tools work smooth and realtime.
- more precise tools than Lr but less automated (If you like "auto" tasks and are fine with the result, Lr will be faster. If you tweak everything manually, C1 gives advantage)
- better* grain, more organic
- better* Black and white
- finer/more precise color control
- skin smoothing / color averaging (sometimes no need for external edit)
- WAY more* detail revealed (or extracted) than from Lr. It seems like new camera/lens compared to Lr.
- Lens specific sharpening (based on specific lens profile and its design)
- more natural* SKIN colors
- for non crucial work, images are mostly fine out of the box (e.g. I shoot my children, load images to C1, export them, finito) , while in Lr I must tweak just about any photo before it's watchable (even least important snapshot)
- auto image enhance actually gives usable results. I would never (!) use Auto in Lr (always washed out look).
- multiple recipes for export at once - Lr have them too, but separate export work in parallel, using more time than one by one.
- it renders my Pentax cameras MUCH more acurate and better than Lr.
What I DISLIKE in Capture One:
- metadata is NOT written into files like in Lr (I shoot DNG's with my Pentax, I don't know how it is with other cameras), so sidecar files are added. I hate clutter, maybe not and issue for most.
- ColorChecker password is near to useless - in Lr I can easily create DNG color profile - but it is less needed than in Lr since my C1 renders Pentax camera WAY better than Lr. I had severe red color problems in Lr, until I created custom DNG profiles. No such problems with oversaturated/exposed reds in C1. So maybe not an issue for most. I can make ICC profile with some elbow grese.
- Extra subscription fee on top of Adobe. I have CC for other Adobe software as well, so using Lr only would be more economical. For photographers only CC you get Photoshop as well in same subscription. So having C1 + Ps is 2x the price. Well one could trade some image quality and tools precision for price, if Lr would work as it should. Since it wastes our time, paying extra saves us money on longer run.
- not nearly as much lens profiles as in Lightroom. BIG diss. But yes, we can adjust that manually. I reckon this is because in Adobe lens profiles corrects only vigneting and barrel, but in C1 also sharpness fall-off; so lenses that have profile benefits more in C1 than Lr. Issue is probably not important to CaNicon shooter - there are ton of profiles, but I have rare Pentax.
- I have some GREAT presets in Lr that I payed for and I love. Yes, Capture One have "styles" too. But for Lr there are thousands of free and non free presets on the web. I must yet discover styles in C1 before I can compare.
So I mostly prefer C1 over Lr anytime.
If I must choose one:
I would choose lightroom if it would work smooth and fast (hear that Adobe!), because it is more convenient and integrated into adobe ecosystem and cheaper and I have great presets and I invested 10 years into mastering it.
But since Adobe Lightroom does not work smooth or fast and was not updated it's process for 5 years, I prefer Capture One for everyday work because it is faster, more accurate and gives me higher quality or control over development.
Reason why I still use Lightroom is because I have total CC subscription and not using it does not save me money. But soon after I replace Premiere...
* Arguable. One would say I can be replicated in Lr as well. But per my knowledge, very hard or impossible. At the end, whe struggle if C1 gives similar out of the box.
Hope it helps.
- no performance issues - tools work smooth and realtime.
- more precise tools than Lr but less automated (If you like "auto" tasks and are fine with the result, Lr will be faster. If you tweak everything manually, C1 gives advantage)
- better* grain, more organic
- better* Black and white
- finer/more precise color control
- skin smoothing / color averaging (sometimes no need for external edit)
- WAY more* detail revealed (or extracted) than from Lr. It seems like new camera/lens compared to Lr.
- Lens specific sharpening (based on specific lens profile and its design)
- more natural* SKIN colors
- for non crucial work, images are mostly fine out of the box (e.g. I shoot my children, load images to C1, export them, finito) , while in Lr I must tweak just about any photo before it's watchable (even least important snapshot)
- auto image enhance actually gives usable results. I would never (!) use Auto in Lr (always washed out look).
- multiple recipes for export at once - Lr have them too, but separate export work in parallel, using more time than one by one.
- it renders my Pentax cameras MUCH more acurate and better than Lr.
What I DISLIKE in Capture One:
- metadata is NOT written into files like in Lr (I shoot DNG's with my Pentax, I don't know how it is with other cameras), so sidecar files are added. I hate clutter, maybe not and issue for most.
- ColorChecker password is near to useless - in Lr I can easily create DNG color profile - but it is less needed than in Lr since my C1 renders Pentax camera WAY better than Lr. I had severe red color problems in Lr, until I created custom DNG profiles. No such problems with oversaturated/exposed reds in C1. So maybe not an issue for most. I can make ICC profile with some elbow grese.
- Extra subscription fee on top of Adobe. I have CC for other Adobe software as well, so using Lr only would be more economical. For photographers only CC you get Photoshop as well in same subscription. So having C1 + Ps is 2x the price. Well one could trade some image quality and tools precision for price, if Lr would work as it should. Since it wastes our time, paying extra saves us money on longer run.
- not nearly as much lens profiles as in Lightroom. BIG diss. But yes, we can adjust that manually. I reckon this is because in Adobe lens profiles corrects only vigneting and barrel, but in C1 also sharpness fall-off; so lenses that have profile benefits more in C1 than Lr. Issue is probably not important to CaNicon shooter - there are ton of profiles, but I have rare Pentax.
- I have some GREAT presets in Lr that I payed for and I love. Yes, Capture One have "styles" too. But for Lr there are thousands of free and non free presets on the web. I must yet discover styles in C1 before I can compare.
So I mostly prefer C1 over Lr anytime.
If I must choose one:
I would choose lightroom if it would work smooth and fast (hear that Adobe!), because it is more convenient and integrated into adobe ecosystem and cheaper and I have great presets and I invested 10 years into mastering it.
But since Adobe Lightroom does not work smooth or fast and was not updated it's process for 5 years, I prefer Capture One for everyday work because it is faster, more accurate and gives me higher quality or control over development.
Reason why I still use Lightroom is because I have total CC subscription and not using it does not save me money. But soon after I replace Premiere...
* Arguable. One would say I can be replicated in Lr as well. But per my knowledge, very hard or impossible. At the end, whe struggle if C1 gives similar out of the box.
Hope it helps.
PS: C1 compared to Lr is NOT the same exerience and not all tools are replacable. Some are same, some similar, some completelly different. I can struggle all day and I cant make RAW image the same in both programs. What I can say is Capture One needs less tweaking to get decent image that Iike. Most of them are fine (usable) straight after loading in. For heavy preset* user Lr would still be faster regardless of Lr problems.
Learning curve in C1 was 1 afternoon. But I use Lightroom for decade. I wonder how that would be for newbies.
* Sometimes I force myself to use digital body as film camera, so I must do it right in camera. Thoose images I do not tweak other than exposure. In that cases I load image into Lr, apply film simulation preset , fix exposure if needed and export it. It is fast than.
Learning curve in C1 was 1 afternoon. But I use Lightroom for decade. I wonder how that would be for newbies.
* Sometimes I force myself to use digital body as film camera, so I must do it right in camera. Thoose images I do not tweak other than exposure. In that cases I load image into Lr, apply film simulation preset , fix exposure if needed and export it. It is fast than.
C1's metadata tools are garbage compared to LR's. That's the only thing currently keeping me on LR - for what I do the ability to quickly add and filter disparate metadata is essential and C1 simply doesn't have the tools for it.
As for tethering reliability, I found that all my LR problems went away when I switched to a USB2 cable, with no noticeable drop in speed (Nikon D800)
As for tethering reliability, I found that all my LR problems went away when I switched to a USB2 cable, with no noticeable drop in speed (Nikon D800)
I recently built a new Windows 10 machine to replace a 4 year old MacBook Pro. The specs on the new machine are:
Intel i7 6800k
32GB DDR4 Ram
MSI Radeon RX480 4Gb GPU
Asus X99-A II Motherboard
LG 27" 4K monitor running at 3840x2160
Lightroom is 2015.10
My performance is about the same or worse running on my new machine vs. my old MacBook pro (i7 2.7ghz 16gb ram) and recently I upgraded to the latest AMD drivers and the develop module crashes lightroom. I have to disable the GPU to get into it. Before upgrading to the latest drivers the GPU would work, but the apps performance would slowly degrade over time. Here are some of the issues I've faced:
- The screen would flash black frequently .
- Sometimes when I clicked on an image, it would flash to another image first the to the image I selected.
- Using the sliders had a serious delay associated with them, sometimes not seeing the results on screen for seconds. For example, moving the exposure slider would not update the image for a couple seconds.
- Sometimes there is a 2-3 second delay moving between images in develop mode.
- Using brushes and spot removal is painfully slow.
These are just some of the more common problems. I've had other issues come up more randomly as well.
I'm going to completely remove my drivers and re-install and see if that helps the GPU crashing problem. Regardless though, even when the GPU setting is enabled, the app is painful to use.
Happy to provide any information to help fix this problem as I'm actively pursuing other apps to replace Lightroom much to my displeasure. It's an amazing app if performed well.
Intel i7 6800k
32GB DDR4 Ram
MSI Radeon RX480 4Gb GPU
Asus X99-A II Motherboard
LG 27" 4K monitor running at 3840x2160
Lightroom is 2015.10
My performance is about the same or worse running on my new machine vs. my old MacBook pro (i7 2.7ghz 16gb ram) and recently I upgraded to the latest AMD drivers and the develop module crashes lightroom. I have to disable the GPU to get into it. Before upgrading to the latest drivers the GPU would work, but the apps performance would slowly degrade over time. Here are some of the issues I've faced:
- The screen would flash black frequently .
- Sometimes when I clicked on an image, it would flash to another image first the to the image I selected.
- Using the sliders had a serious delay associated with them, sometimes not seeing the results on screen for seconds. For example, moving the exposure slider would not update the image for a couple seconds.
- Sometimes there is a 2-3 second delay moving between images in develop mode.
- Using brushes and spot removal is painfully slow.
These are just some of the more common problems. I've had other issues come up more randomly as well.
I'm going to completely remove my drivers and re-install and see if that helps the GPU crashing problem. Regardless though, even when the GPU setting is enabled, the app is painful to use.
Happy to provide any information to help fix this problem as I'm actively pursuing other apps to replace Lightroom much to my displeasure. It's an amazing app if performed well.
How come developers of Lr does not "see" all the problems? Even computer geeks should see that real life usage of Lr sucks.
I think that some users and apparently ALL the developers never stress the system with heavily edited photographs or needing to cull a lot of images quickly. So the performance problems of Lightroom are well known in general in the user community, but it's a great secret to the developers who still believe that it's a system by system issue.
Rikk Flohr, Official Rep
Another question for the group - Windows Users: are any/all of you actively using Windows Defender as your security software?
Other Windows and Mac users: Security software in use?
Other Windows and Mac users: Security software in use?
Windows defender is the only security software I'm using.
No security software in use other than what's built in to Mac OS.
Windows Defender here.
Just Defender.
Defender turned off, using Avira.
All I've got running constantly is Windows Defender, and I occasionally run MalwareBytes, but never leave it running in the background.
Kaspersky here. Defender off.
Same as Matthew. Defender and occasionally MalwarBytes.
Having the same problem (will write a post below)
- Only using windows defender
- Only using windows defender
Using Bitdefender on Win 10 x64
I just posted some very good results I got combining a patch posted by Simon Chen, along with affinity masking posted by John Ellis, over on the other Lightroom-is-really-slow thread (https://feedback.photoshop.com/photoshop_family/topics/lightroom-clone-and-brush-tool-can-not-stress...). I suspect the answer will vary for different chipsets and different tasks, but I'm hoping that Adobe is getting closer to figuring out the problems in multi-core implementations.
Is this compatible with Windows? I'll have to look into it tomorrow as it looks like a promising short-term bandaid.
Yes -- I'm running Windows 7. Basically, you add a config.lua file to your Lightroom folder as described by Simon Chen. Then you open a cmd window, where you can start Lightroom with (in my case) half my processors turned off. Performance was dramatically improved. I haven't done a long editing session yet, so I'll add more performance commentary later.
WOW. LR is way faster with the config. I'm 4790K i7 (oc'd) with 32GB of oc'd ram and 280x GPU on mac sierra. 4k monitor, GPU enabled, Smart Preview edit enabled.
(Edited)
I put it here: \AppData\Roaming\Adobe\Lightroom
How would I verify it's running?
How would I verify it's running?
Look at your 'System Info" (under the help menu). You should see a line that says:
Config.lua flags:
Develop.AdjustMaximumThreadCount = 0.51
Its about a 3rd of the way down, under the 'Installed Plugins'
Config.lua flags:
Develop.AdjustMaximumThreadCount = 0.51
Its about a 3rd of the way down, under the 'Installed Plugins'
Got it, thanks Mike! I'll see what it looks like...
Must admit that this thread does not surprise me at all. I have a gaming PC that I considered to be high spec some time ago. I was so excited when I was building it, could not wait to start working with LR6.
I was so disappointed.
Had to invest in another software to sort the images as LR was too laggy. Develop module tools are also very laggy - zooming an image, spot removal, brush, you name it. At some point it just lags so much to a point I am not clear if it has crashed. Closing (killing the task in Windows) and re-opening LR helps a bit. This is on a machine with 16GB RAM, Geforce GTX 970, SSD drive. Such a shame. And the number of blog posts and articles I have read about "speeding up LR"... :/
I was so disappointed.
Had to invest in another software to sort the images as LR was too laggy. Develop module tools are also very laggy - zooming an image, spot removal, brush, you name it. At some point it just lags so much to a point I am not clear if it has crashed. Closing (killing the task in Windows) and re-opening LR helps a bit. This is on a machine with 16GB RAM, Geforce GTX 970, SSD drive. Such a shame. And the number of blog posts and articles I have read about "speeding up LR"... :/
"And the number of blog posts and articles I have read about "speeding up LR"... :/" -> they all say same. Update drivers, increase cache (I have it 99 GB on separate dedicated SSD); optimize catalog, etc. You can not build fast enough machine since Lr does not use resources other than when exporting final images. Sad.
Yeah, I too invested in Photomechanic to filter and tag photos, as LR was simply too slow for the job (Especially considering I'd have to leave it overnight to import!) PhotoMechanic manages to be very, very fast for navigating and organising - but I feel like it shouldn't be a necessary purchase - LR has all the tools one needs, except speed.
Pro-user, 1M shots through LR since beta. My main issues at the moment with 4790k@4.7G w/32GB and SSD previews+catalog and Smart DNG preview edit enabled are: screen flickers constantly with R9 280x GPU enabled. Sometimes, I get a flicker when I use any sliders where the screen shows the previous edit state then new adjustment then back to previous and then settles on new state. I also get a blacked-out image area which seems to be tied to minimize/maximize app switching. I can kill LR and reload to get the photo space back. GPU does speed up my main slider renderings to screen on my 4k monitor. But, GPU does make the clone/heal tool unbearable.
Those complaining that LR is slow in the Library aren't building 1:1 previews or they are comparing to PM which, I believe, pulls the embedded previews not new previews based on import settings. One of the problems with LR is that you must learn all of the *tricks*. Shouldn't the software be smart enough to guide users to the best performance? Shouldn't rendering pause when the user is interacting with the UI and resume 100% cpu load when the user walks away from the computer (FCPX). Shouldn't the user be able to queue up jobs and pause them? Shouldn't the user be able to choose between precision and performance (Develop mode)?
Those complaining that LR is slow in the Library aren't building 1:1 previews or they are comparing to PM which, I believe, pulls the embedded previews not new previews based on import settings. One of the problems with LR is that you must learn all of the *tricks*. Shouldn't the software be smart enough to guide users to the best performance? Shouldn't rendering pause when the user is interacting with the UI and resume 100% cpu load when the user walks away from the computer (FCPX). Shouldn't the user be able to queue up jobs and pause them? Shouldn't the user be able to choose between precision and performance (Develop mode)?
Mine is quite slow even with 1:1 previews/smart previews. I would not have a problem with having an option to let LR pull embedded previews as I am mainly using library module to sort and rate my photos right after the shoot.
I build 1:1 previews (which takes 3+ hours for 1000 RAF files, so long as I don't touch my computer for anything else, set it to Max Performance mode, and let the fan crank full speed the whole time while my CPU sits at 100% like a raging volcano) and it helps a bit with moving from photo to photo to rate and select, but the second I start actually making edits in the develop module, things slow back to a crawl. Adjusting exposures, doing gradient adjustments, or heaven forbid, trying to use the spot-heal brush all take multiple seconds for the results to show up on-screen.
There are only so many "tricks" and even if they worked, they shouldn't be necessary. Something with nearly the same features (like Capture one) has far less issues when it comes to doing edits with good performance.
There are only so many "tricks" and even if they worked, they shouldn't be necessary. Something with nearly the same features (like Capture one) has far less issues when it comes to doing edits with good performance.
I also build 1:1 previews and it barely helps at all with the slowness
I really can't understand why there is such a huge performance difference between PhotoMechanic and LR, even after giving LR 1 hour to generate previews.
But let's even leave PM. Windows 8 built in photo viewer (I think it's just called "Photos") sweeps through RAW files as fast as PM. Instant. Previews. It does not read xmp files so you cannot see edits in that but who cares when sorting uneditied photos. Perhaps Adobe should allows us to enable that in Library module. Or introduce a new module called "Sort" - ultra fast, minimal interface module for quickly browsing through our images.
But let's even leave PM. Windows 8 built in photo viewer (I think it's just called "Photos") sweeps through RAW files as fast as PM. Instant. Previews. It does not read xmp files so you cannot see edits in that but who cares when sorting uneditied photos. Perhaps Adobe should allows us to enable that in Library module. Or introduce a new module called "Sort" - ultra fast, minimal interface module for quickly browsing through our images.
That's impossible. On my machine, with 1:1 in Library, it's nearly instant. There is 0.0% rendering time. I can arrow through shots with no delay. I cull at about 1500/hr. Are you rendering 1:1 and then culling in Develop module? I'm talking zero delay to a 4k monitor.
(Edited)
@Seb - PM is pulling the 1/4-size JPEG preview if you are shooting Canon. So, if 24MP Raw, you are sifting through 6MP heavily-compressed jpeg not 1:1 24 megapixel JPEG. What happens in PM when you zoom 1:1?? (I haven't used PM)
It renders - there is a short delay but nothing like LR. Obviously it's not rendering a processing stack, but it's certainly not frustratingly slow.
At 25 images per minute, you must be swapping between them in < 2s. What is your system? I'd kill to be able to do that!
At 25 images per minute, you must be swapping between them in < 2s. What is your system? I'd kill to be able to do that!
Not to be funny but issues that users are describing are not just relevant for LR 2015.10. I, at least, am experiencing those issues since I can remember. Always thought my machine was too slow, until I upgraded.
(Edited)
I'm very jealous. What camera are you using, and what sorts of editing do you do?
What I am trying to say is that I always thought that my machine was too slow, upgraded and realised it is LR, not my machine.
(Edited)
I see. Well, I have a fairly monstrous system, with an overclocked i7 processor, 32Gigs of very fast ram, and some extremely quick SSDs, and a huge cache, and I have tons of issues, so if the answer is "buy a better computer" then I'm going to need to win some sort of lottery to be able to afford a better setup than I've currently got.
Agree 100%. Like others have said in this thread - you cannot build a computer fast enough to handle LR well.
By the way, I run an overclocked i5-2500k, 16GB RAM, GTX 970, SSD. Cache set to 20GB.
By the way, I run an overclocked i5-2500k, 16GB RAM, GTX 970, SSD. Cache set to 20GB.
(Edited)
Matthew, Seb -- how many CPU's are you running? There's a significant issue in LR where adding cores actually destroys performance. I posted some test data and the way I'm planning to run over on this thread: https://feedback.photoshop.com/photoshop_family/topics/lightroom-clone-and-brush-tool-can-not-stress...
Don't know if it will help you, but having read every "speed up lightroom" thread out there, this is the first time I've found anything that makes a difference.
Don't know if it will help you, but having read every "speed up lightroom" thread out there, this is the first time I've found anything that makes a difference.
Mike, my i7-4800MQ has 4 cores and "8 Logical processors" according to my task manager. I'll follow your link and do some reading.
That's just the thing though guys - some people out there (With inferior specs, or Macs) don't exhibit these symptoms. It would be a no brainer to blame straight Lightroom for the delays, but as some people don't experience them, it's got to be Lightroom in conjunction with something that's causing the terrible performance.
Thanks Mike, did the config.lue patch but cannot see any difference.
Denyer, I am not saying it is just Lightroom but since it's Adobe's product, they should be identifying what it is that's causing issues.
Denyer, I am not saying it is just Lightroom but since it's Adobe's product, they should be identifying what it is that's causing issues.
The difference could be the functions that people are using. The primary delays I experience are in D mode on photographs that have had a number of brush/clone/heal actions. If someone does not do a lot of that type of editing then they might be fine in D mode.
As for the slowdowns in G mode scrolling through photographs that lack 1-1 previews, perhaps those who don't experience the problem are shooting smaller numbers of photographs per shoot?
As for the slowdowns in G mode scrolling through photographs that lack 1-1 previews, perhaps those who don't experience the problem are shooting smaller numbers of photographs per shoot?
Mike S - it looks like I'm running the same processor as you, so I'm hoping to get the same results you got, but I'm struggling with getting the Config file to take effect in my Lightroom installation. My Flags stay at "none" in system Info. I'm thinking my "Show Lightroom Presets Folder" might not be taking me to the correct folder.
Matthew -- Mine took me to C:\Users\{your name}\AppData\Roaming\Adobe, and I dropped the config.lua file into the Lightroom folder (so inside C:\Users\{your name}\AppData\Roaming\Adobe\Lightroom.
Matthew -- Mine took me to C:\Users\{your name}\AppData\Roaming\Adobe, and I dropped the config.lua file into the Lightroom folder (so inside C:\Users\{your name}\AppData\Roaming\Adobe\Lightroom.
Sean -- How many cores are you running, and did you also change affinity (from a cmd window -- can't do it after the process starts running). I didn't get much improvement from the config.lua file by itself -- it was the combination of that plus the affinity change. Also, did you verify that you had the config.lua file actually running (see it in system info)? If you have a multi-core system that doesn't benefit at all from those two changes, it just highlights why Adobe is having so much trouble figuring this out.
Dropping the file in the presets folder did not work for me either as I have LR set up to store presets with catalog. However, it did work when I copied it into:
C:\Program Files\Adobe\Adobe Lightroom
C:\Program Files\Adobe\Adobe Lightroom
Seb -- meant to address the above to you, not Sean, based on you saying that config.lua didn't help:
Seb -- How many cores are you running, and did you also change affinity (from a cmd window -- can't do it after the process starts running). I didn't get much improvement from the config.lua file by itself -- it was the combination of that plus the affinity change. Also, did you verify that you had the config.lua file actually running (see it in system info)? If you have a multi-core system that doesn't benefit at all from those two changes, it just highlights why Adobe is having so much trouble figuring this out.
Seb -- How many cores are you running, and did you also change affinity (from a cmd window -- can't do it after the process starts running). I didn't get much improvement from the config.lua file by itself -- it was the combination of that plus the affinity change. Also, did you verify that you had the config.lua file actually running (see it in system info)? If you have a multi-core system that doesn't benefit at all from those two changes, it just highlights why Adobe is having so much trouble figuring this out.
I am running 4 cores.
Yes, I did check sys info in LR and it stated = 0.51 under config.lua flags.
I only did the config patch without anything else but will try the rest as well.
I do appreciate that if it would be easy to figure out, they would have fixed it by now. So what does the affinity do exactly?
Is it a matter of executing "/affinity F cmd.exe /c "c:\Program Files\Adobe\Adobe Lightroom\lightroom.exe" in Windows run?
Yes, I did check sys info in LR and it stated = 0.51 under config.lua flags.
I only did the config patch without anything else but will try the rest as well.
I do appreciate that if it would be easy to figure out, they would have fixed it by now. So what does the affinity do exactly?
Is it a matter of executing "/affinity F cmd.exe /c "c:\Program Files\Adobe\Adobe Lightroom\lightroom.exe" in Windows run?
(Edited)
Seb -- on a 4 core system, you may want to try a mask of '3' or '5' (to get to 2 core usage) rather than 'F' or '55'. I found the best results when I cut my core usage in half. Of course, that's just my anecdotal result. Perhaps Adobe will weigh in on this at some point with something more systematic.
Mike and Seb, thanks for the the tip about putting it into the Lightroom folder. That did it for me.
Mike, do you have more details on the additional Affinity change? I can't seem to find any information about that, and I don't know what it's referring to.
Mike, do you have more details on the additional Affinity change? I can't seem to find any information about that, and I don't know what it's referring to.
https://feedback.photoshop.com/photoshop_family/topics/lightroom-clone-and-brush-tool-can-not-stress...
Search the page for 'Ellis' -- the first time he pops up, he describes the procedure to start Lightroom with certain processors turned off (known as setting affinity)
Search the page for 'Ellis' -- the first time he pops up, he describes the procedure to start Lightroom with certain processors turned off (known as setting affinity)
Thanks Mike.
I did both steps, and then went and cleared out 1:1 previews for 775 photos, and then started rebuilding them. Before these changes, it would spike to 100% CPU usage and take forever. Now, I'm staying around 50% CPU usage (Makes sense since I told it to use only half my cores) and while it's still seeming to take a while, the system is at least running a bit cooler.
I did both steps, and then went and cleared out 1:1 previews for 775 photos, and then started rebuilding them. Before these changes, it would spike to 100% CPU usage and take forever. Now, I'm staying around 50% CPU usage (Makes sense since I told it to use only half my cores) and while it's still seeming to take a while, the system is at least running a bit cooler.
I didn't do any benchmarking on building previews -- just in the develop module. But its worth timing the operation, then repeating it under 'normal' conditions, just to satisfy yourself that there's real improvement or not. I'm definitely curious about what you find.
Is there a way for me to receive a single daily digest email of this conversation rather than getting a separate email for every single comment? I'd like to track this conversation but getting all theses emails is too tedious. Thank you.
And you just got email that I liked your comment and separate email for this peace of writing. :(
Guys... I have enough. We are dancing rainmaking ritual here, since we all know it will not be any different, but we perform it anyway out of desperation. Until Adobe will fixed it (or someone else). I'm cured for next few jobs from temptation to waste 10's of hours seeking nonexisting solution on desperate users's forum.
This afinity is nonsense. I excluded half of my logical cores (so 6 instead of 12) and it just goes slower. For editing it is not much of a difference. But for creating prewiews significant. I can tell my system is fast since importing and creating previrew are really fast. Exporting as well. Just editing. And NO, I do not mean how fast image renders (that too), but I hate that sliders that used to be smooth and real time are now choppy, sticky, laggy and during changes image got blurred, panels or sliders or part of images goes blank, and so on.
Yes, developers probably load handfull of images and try them. Fine, if you trying image per se. But culling on Lightroom is not an option anymoore. You nned to switch images fast, zoom in zoom out, decide which is which, maybe make simple exposure adjustment. Sure, creating 1:1 previews helps here. But still... c'mon, we are paying a lot.
This afinity is nonsense. I excluded half of my logical cores (so 6 instead of 12) and it just goes slower. For editing it is not much of a difference. But for creating prewiews significant. I can tell my system is fast since importing and creating previrew are really fast. Exporting as well. Just editing. And NO, I do not mean how fast image renders (that too), but I hate that sliders that used to be smooth and real time are now choppy, sticky, laggy and during changes image got blurred, panels or sliders or part of images goes blank, and so on.
Yes, developers probably load handfull of images and try them. Fine, if you trying image per se. But culling on Lightroom is not an option anymoore. You nned to switch images fast, zoom in zoom out, decide which is which, maybe make simple exposure adjustment. Sure, creating 1:1 previews helps here. But still... c'mon, we are paying a lot.
With your sliders problem, my guess is that it is a graphics driver problem. Are you using the latest graphics update? Try a different graphics card - I had a LR problem years ago with a Radeon card that was cured by switching to a NVidia card. I now use a NVidia quadro since they are more reliable than gaming cards. If you can't afford a new graphics card, borrow one for a test. Poor graphics drivers can cause all sorts of problems - just look at the list of problems listed in the manufacturers info for each graphics card/driver (some games will work, others won't, and this list changes for each update).
Bob frost
Could this be why we don't see any Mac users complaining here? Perhaps Adobe needs to certify graphics hardware for this important software.
I have tried both nvidia and amd gpus and the performance is still crap. Also tried disabling GPU in LR and same crappy result. I've seen a lot of complaints from Mac users in the web as well so no, this is not isolated to PC crowd. Download a trial of capture one pro and you will see how a properly engineered software runs. I am not sure how much longer I can tolerate LR before I jump ship.
The only lags I really see is when I'm culling and need to fly through a lot of images. I have recently bought FastRawViewer for a pittance. It displays RAW files very fast, lets you tag with colors and/or stars that Lr reads from the XMP. I suggested in another post (https://feedback.photoshop.com/photoshop_family/topics/module-suggestion-organize) that Lr needed a more fully featured organization mode but perhaps part of that should be a culling mode as well. Good luck with the sliders and so on. I don't see that at all.
Out of curiosity, what viewer did you get? Do you copy the files to another folder first after culling and then import to LR?
It is called FastRawViewer at fastrawviewer.com. I'm still experimenting with the workflow but you can either;
- import thru Lr then switch to FRV, rate, label and cull, then tell Lr to synchronize the folder or
- bring the images into a folder without Lr, do all the culling then import the folder into Lr
Steve, is it notably faster when culling? I saw this video where they compare the histogram information that we get from Adobe vs this their histogram where it's reading 100% RAW data instead of the JPEG preview data that Lightroom reads and subsequently produces https://www.youtube.com/watch?v=6xWHaSz_KDM&t=378s
I think it is. I notice some lag time when popping through the images in Lr but almost none in this viewer. However, I'm not really using all the features or worrying about the histogram and so on. When culling I just want to see a screen sized image to evaluate basic exposure, focus and composition.
Melissa Rios, Lightroom Support Product Manager
Denyer Ec
Rikk Flohr, Official Rep
Art M.
Why did Lightroom performance in D mode fall off a cliff. I often find myself watching a spinning ball because I did a small clone. And why are most versions so buggy?
The one CLUE that I can give you is that D mode gets really slow in an image after I have made a few edits. The first edit is pretty fast but after a few edits it bogs down severely. (Whether GPU is on or off. I did increase the cache and I leave 100 gig open on SSD).
With latest version sometimes I move a basic slider and there is no effect. It happens randomly. Only a handful of times so far. I dont see any pattern yet.
MacBook Pro 2015 13". I7. 16gig memory.
Is Adobe management aware that all is not well here?
Rikk Flohr, Official Rep
We are being level.
In my personal non-Adobe environments (namely Win 10 Desktop and Mac OSx 10.12.4) Lightroom runs smoothly and quickly. It is as fast or faster than 5.7.1 in my studio environment even considering I was using a Canon 5d Mark II previously and recently upgraded to a Mark IV with much larger files. My 2012 MacbookPro runs Lightroom quite zippy on modest specs even when tethering for three days straight!
Many users are reporting better performance. Some users are reporting poor performance. We can acknowledge both of those.
The problem with sites like this and other support sites is that there aren't droves of people who come in special just to say "Wow this is working great." Those people continue to work and are blissfully unaware that small groups of users are experiencing issues. Users only come here when they have a problem and the self-selective bias makes things appear more widespread than they really are.
We are working with users who are having problems with performance to determine where Lightroom's bottlenecks are the culprit and where individual system configurations need to be adjusted and, in some cases, fixed.
Art, we are happy to work with you to see if we can resolve Lightroom's poor performance with your system. It will require much more information from you. Would you like to participate?
As to your final question: Adobe Lightroom Management and follows posts in this forum. Occasionally, they will respond on a thread.
Art M.
Mihael Tominšek
I would bring my PC on foot to you center if that helped. Yes we would like to participate... Anything...
I can just say my experience with Premiere where exactly same PC (same installation) is working SLOW with CC2015 and FAST with CC2017. Obviosly Adobe did something that LAG gone. I hope Lr will once be fast too.
Rikk Flohr, Official Rep
The first thing we need is a complete - detailed description of your system.
Next we need a complete, detailed description of your Lightroom catalog and how the bits are arrayed across your various storage devices./
Lastly, we need specific operations with elapsed times for those operations.
Those three items allow us to: find, prepare, and perform on a test system to see if your behavior is typical for what we normally see or if it is substantially longer. Based upon that we can make a judgement as to bug, hardware, or system specific configuration issues ( or any combination) are in play.
Mihael Tominšek
I'm even prepared to erase one computer and test on clean install.
... but apart from excessive lagginess here and there (usually after new update), the Lr never was fast... or for a long time. A lot of hardware / software changes during the years. The brush lag is know for last few versions...
Mike S
I've been following these threads, and have been doing my own testing. I may have data that can help.
- I created a new catalog, with 40 raw images from an Olympus E-M1. The images are stored on my D: drive, a WD 750GB hard drive. The catalog is on my C: drive, a 256GB SSD.
- I compared performance of versions 2015.4 and 2015.10. I've run 2015.4 since it came out, and its been fast and stable.
My test procedure:- Open Lightroom, and allow memory usage to stabilize. GPU acceleration turned off. Go to Develop module.
- Use arrow key to move right through 10 images, then move back left through the same 10, returning to the original shot. This simply tests how quickly the Develop module can load and display the same images.
- For 20 images: apply a preset (highlights to 0, shadows to 100, clarity to 20, camera profile 'Natural'). Then 'Reset' image. Move to the next image. Take split times after 5, 10, 15, and 20 images.
Results:Moving through 10 images right, then left: 2015.4 = 23s, 2015.10 = 33s
Develop 20 images. Splits for each set of 5:
2015.4 = 22s, 24s, 22s, 21s
2015.10 = 39s, 63s, 87s, 123s
I repeated the 2015.10 tests twice (restarted system in between), and got virtually identical results. The fact that 2015.10 is noticeably slower can be seen in the first 5 images as well as the simple movement test. The steady performance degradation is obvious too. By the end of the 20 images, Lightroom was basically unusable and had to be restarted.
Memory utilization on my 16GB RAM system was below 50% throughout the testing.
I haven't tested all the intermediate versions between 15.4 and 15.10 because I'm hoping this is enough to get your own systems set up to duplicate the problem.
The only other data point I can add is that you fixed this once: this behavior existed in Lightroom version 5, but went away when version 6 (now 2015.x under the CC naming) came out. Version 6/2015 stayed fast through update 4, then broke somewhere between update 5 and now.
Let me know what else I can provide. System info is pasted below:
Lightroom version: CC 2015.10 [ 1111918 ]License: Creative Cloud
Operating system: Windows 7
Version: 6.1
Application architecture: x64
System architecture: x64
Logical processor count: 8
Processor speed: 2.6 GHz
Built-in memory: 16311.1 MB
Real memory available to Lightroom: 16311.1 MB
Real memory used by Lightroom: 1364.3 MB (8.3%)
Virtual memory used by Lightroom: 1515.9 MB
GDI objects count: 805
USER objects count: 2264
Process handles count: 1323
Memory cache size: 897.2MB / 3821.7MB (23.5%)
Maximum thread count used by Camera Raw: 8
Camera Raw SIMD optimization: SSE2,AVX,AVX2
Camera Raw virtual memory: 841MB / 8155MB (10%)
System DPI setting: 120 DPI
Desktop composition enabled: Yes
Displays: 1) 1920x1200, 2) 1920x1080
Input types: Multitouch: No, Integrated touch: No, Integrated pen: No, External touch: No, External pen: No, Keyboard: No
Graphics Processor Info:
GeForce GTX 780M/PCIe/SSE2
Check OpenGL support: Passed
Vendor: NVIDIA Corporation
Version: 3.3.0 NVIDIA 372.90
Renderer: GeForce GTX 780M/PCIe/SSE2
LanguageVersion: 3.30 NVIDIA via Cg compiler
Application folder: C:\Program Files\Adobe\Adobe Lightroom
Library Path: C:\Lightroom Catalogs\Test Cat\Test Cat.lrcat
Settings Folder: C:\Users\Mike\AppData\Roaming\Adobe\Lightroom
Installed Plugins:
1) AdobeStock
2) ColorChecker Passport
3) HDR Efex Pro 2
4) Helicon Focus Export
5) Merge to 32-bit
6) ON1 Effects Standalone 10
Config.lua flags: None
Adapter #1: Vendor : 10de
Device : 119f
Subsystem : 5ae1028
Revision : a1
Video Memory : 4026
AudioDeviceIOBlockSize: 1024
AudioDeviceName: Speakers (Realtek High Definition Audio)
AudioDeviceNumberOfChannels: 2
AudioDeviceSampleRate: 48000
Build: LR5x8
Direct2DEnabled: false
GL_ACCUM_ALPHA_BITS: 16
GL_ACCUM_BLUE_BITS: 16
GL_ACCUM_GREEN_BITS: 16
GL_ACCUM_RED_BITS: 16
GL_ALPHA_BITS: 0
GL_BLUE_BITS: 8
GL_DEPTH_BITS: 24
GL_GREEN_BITS: 8
GL_MAX_3D_TEXTURE_SIZE: 2048
GL_MAX_TEXTURE_SIZE: 16384
GL_MAX_TEXTURE_UNITS: 4
GL_MAX_VIEWPORT_DIMS: 16384,16384
GL_RED_BITS: 8
GL_RENDERER: GeForce GTX 780M/PCIe/SSE2
GL_SHADING_LANGUAGE_VERSION: 4.50 NVIDIA
GL_STENCIL_BITS: 8
GL_VENDOR: NVIDIA Corporation
GL_VERSION: 4.5.0 NVIDIA 372.90
GPUDeviceEnabled: false
OGLEnabled: true
GL_EXTENSIONS: GL_AMD_multi_draw_indirect GL_AMD_seamless_cubemap_per_texture GL_ARB_arrays_of_arrays GL_ARB_base_instance GL_ARB_bindless_texture GL_ARB_blend_func_extended GL_ARB_buffer_storage GL_ARB_clear_buffer_object GL_ARB_clear_texture GL_ARB_clip_control GL_ARB_color_buffer_float GL_ARB_compatibility GL_ARB_compressed_texture_pixel_storage GL_ARB_conservative_depth GL_ARB_compute_shader GL_ARB_compute_variable_group_size GL_ARB_conditional_render_inverted GL_ARB_copy_buffer GL_ARB_copy_image GL_ARB_cull_distance GL_ARB_debug_output GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_depth_texture GL_ARB_derivative_control GL_ARB_direct_state_access GL_ARB_draw_buffers GL_ARB_draw_buffers_blend GL_ARB_draw_indirect GL_ARB_draw_elements_base_vertex GL_ARB_draw_instanced GL_ARB_enhanced_layouts GL_ARB_ES2_compatibility GL_ARB_ES3_compatibility GL_ARB_ES3_1_compatibility GL_ARB_ES3_2_compatibility GL_ARB_explicit_attrib_location GL_ARB_explicit_uniform_location GL_ARB_fragment_coord_conventions GL_ARB_fragment_layer_viewport GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_framebuffer_no_attachments GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_geometry_shader4 GL_ARB_get_program_binary GL_ARB_get_texture_sub_image GL_ARB_gl_spirv GL_ARB_gpu_shader5 GL_ARB_gpu_shader_fp64 GL_ARB_gpu_shader_int64 GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_imaging GL_ARB_indirect_parameters GL_ARB_instanced_arrays GL_ARB_internalformat_query GL_ARB_internalformat_query2 GL_ARB_invalidate_subdata GL_ARB_map_buffer_alignment GL_ARB_map_buffer_range GL_ARB_multi_bind GL_ARB_multi_draw_indirect GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_occlusion_query2 GL_ARB_parallel_shader_compile GL_ARB_pipeline_statistics_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_program_interface_query GL_ARB_provoking_vertex GL_ARB_query_buffer_object GL_ARB_robust_buffer_access_behavior GL_ARB_robustness GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_seamless_cube_map GL_ARB_seamless_cubemap_per_texture GL_ARB_separate_shader_objects GL_ARB_shader_atomic_counter_ops GL_ARB_shader_atomic_counters GL_ARB_shader_ballot GL_ARB_shader_bit_encoding GL_ARB_shader_clock GL_ARB_shader_draw_parameters GL_ARB_shader_group_vote GL_ARB_shader_image_load_store GL_ARB_shader_image_size GL_ARB_shader_objects GL_ARB_shader_precision GL_ARB_shader_storage_buffer_object GL_ARB_shader_subroutine GL_ARB_shader_texture_image_samples GL_ARB_shader_texture_lod GL_ARB_shading_language_100 GL_ARB_shading_language_420pack GL_ARB_shading_language_include GL_ARB_shading_language_packing GL_ARB_shadow GL_ARB_sparse_buffer GL_ARB_sparse_texture GL_ARB_stencil_texturing GL_ARB_sync GL_ARB_tessellation_shader GL_ARB_texture_barrier GL_ARB_texture_border_clamp GL_ARB_texture_buffer_object GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_buffer_range GL_ARB_texture_compression GL_ARB_texture_compression_bptc GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map GL_ARB_texture_cube_map_array GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_gather GL_ARB_texture_mirror_clamp_to_edge GL_ARB_texture_mirrored_repeat GL_ARB_texture_multisample GL_ARB_texture_non_power_of_two GL_ARB_texture_query_levels GL_ARB_texture_query_lod GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_texture_rgb10_a2ui GL_ARB_texture_stencil8 GL_ARB_texture_storage GL_ARB_texture_storage_multisample GL_ARB_texture_swizzle GL_ARB_texture_view GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_transform_feedback_instanced GL_ARB_transform_feedback_overflow_query GL_ARB_transpose_matrix GL_ARB_uniform_buffer_object GL_ARB_vertex_array_bgra GL_ARB_vertex_array_object GL_ARB_vertex_attrib_64bit GL_ARB_vertex_attrib_binding GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_vertex_type_10f_11f_11f_rev GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_ARB_window_pos GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_bindable_uniform GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_depth_bounds_test GL_EXT_direct_state_access GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXTX_framebuffer_mixed_formats GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_polygon_offset_clamp GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_shader_objects GL_EXT_separate_specular_color GL_EXT_shader_image_load_store GL_EXT_shader_integer_mix GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_array GL_EXT_texture_buffer_object GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_latc GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_shared_exponent GL_EXT_texture_sRGB GL_EXT_texture_sRGB_decode GL_EXT_texture_storage GL_EXT_texture_swizzle GL_EXT_timer_query GL_EXT_transform_feedback2 GL_EXT_vertex_array GL_EXT_vertex_array_bgra GL_EXT_vertex_attrib_64bit GL_EXT_window_rectangles GL_EXT_import_sync_object GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KHR_context_flush_control GL_KHR_debug GL_KHR_no_error GL_KHR_robust_buffer_access_behavior GL_KHR_robustness GL_KTX_buffer_region GL_NV_alpha_to_coverage_dither_control GL_NV_bindless_multi_draw_indirect GL_NV_bindless_multi_draw_indirect_count GL_NV_bindless_texture GL_NV_blend_equation_advanced GL_NV_blend_square GL_NV_command_list GL_NV_compute_program5 GL_NV_conditional_render GL_NV_copy_depth_to_color GL_NV_copy_image GL_NV_depth_buffer_float GL_NV_depth_clamp GL_NV_draw_texture GL_NV_draw_vulkan_image GL_NV_ES1_1_compatibility GL_NV_ES3_1_compatibility GL_NV_explicit_multisample GL_NV_fence GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_framebuffer_multisample_coverage GL_NV_geometry_shader4 GL_NV_gpu_program4 GL_NV_internalformat_sample_query GL_NV_gpu_program4_1 GL_NV_gpu_program5 GL_NV_gpu_program5_mem_extended GL_NV_gpu_program_fp64 GL_NV_gpu_shader5 GL_NV_half_float GL_NV_light_max_exponent GL_NV_multisample_coverage GL_NV_multisample_filter_hint GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_parameter_buffer_object GL_NV_parameter_buffer_object2 GL_NV_path_rendering GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_shader_atomic_counters GL_NV_shader_atomic_float GL_NV_shader_buffer_load GL_NV_shader_storage_buffer_object GL_NV_texgen_reflection GL_NV_texture_barrier GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_multisample GL_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_texture_shader3 GL_NV_transform_feedback GL_NV_transform_feedback2 GL_NV_uniform_buffer_unified_memory GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_attrib_integer_64bit GL_NV_vertex_buffer_unified_memory GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_NVX_conditional_render GL_NVX_gpu_memory_info GL_NVX_multigpu_info GL_NVX_nvenc_interop GL_NV_shader_thread_group GL_NV_shader_thread_shuffle GL_KHR_blend_equation_advanced GL_SGIS_generate_mipmap GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_slice_accum GL_WIN_swap_hint WGL_EXT_swap_control
Mihael Tominšek
I have i7-3920K at 4.1 Ghz / 12 logical cores
32GB ram 2133
GTX 770 4GB
Windows 7 on (dedicated) SSD
(Tested) images on 4TB hard drive
Catalog on (dedicated) SSD
Cache 99 GB on yet another (dedicated) SSD
It seems all theese SSD's help on loading image, but regular editing is not affected by them. Lr 2015.10 is by feel 10-20% slower than before update. But that is notthing since it was not fast even before. What annoys is that system clogs up after a while.
Lightroom version: CC 2015.10 [ 1111918 ]License: Creative CloudOperating system: Windows 7 Version: 6.1Application architecture: x64System architecture: x64Logical processor count: 12Processor speed: 3,2 GHzBuilt-in memory: 32692,0 MBReal memory available to Lightroom: 32692,0 MBReal memory used by Lightroom: 645,0 MB (1,9%)Virtual memory used by Lightroom: 741,0 MBGDI objects count: 628USER objects count: 1492Process handles count: 1315Memory cache size: 83,1MB / 7917,0MB (1,1%)Maximum thread count used by Camera Raw: 12Camera Raw SIMD optimization: SSE2,AVXCamera Raw virtual memory: 18MB / 16346MB (0%)System DPI setting: 96 DPIDesktop composition enabled: YesDisplays: 1) 1920x1080, 2) 1920x1080Input types: Multitouch: No, Integrated touch: No, Integrated pen: No, External touch: No, External pen: No, Keyboard: NoGraphics Processor Info: GeForce GTX 770/PCIe/SSE2
Check OpenGL support: Passed
Vendor: NVIDIA Corporation
Version: 3.3.0 NVIDIA 376.09
Renderer: GeForce GTX 770/PCIe/SSE2
LanguageVersion: 3.30 NVIDIA via Cg compiler
Application folder: C:\Program Files\Adobe\Adobe LightroomLibrary Path: D:\Lightroom\Lightroom Catalog.lrcatSettings Folder: C:\Users\STUDIO\AppData\Roaming\Adobe\LightroomInstalled Plugins: 1) AdobeStock2) Canon Tether Plugin3) ColorChecker Passport4) DxO OpticsPro 105) DxO OpticsPro 10 Importer6) Facebook7) Flickr8) Leica Tether Plugin9) Nikon Tether PluginConfig.lua flags: NoneAdapter #1: Vendor : 10de Device : 1184 Subsystem : 84651043 Revision : a1 Video Memory : 1989AudioDeviceIOBlockSize: 1024AudioDeviceName: Speakers (Realtek High Definition Audio)AudioDeviceNumberOfChannels: 2AudioDeviceSampleRate: 48000Build: LR5x8Direct2DEnabled: falseGL_ACCUM_ALPHA_BITS: 16GL_ACCUM_BLUE_BITS: 16GL_ACCUM_GREEN_BITS: 16GL_ACCUM_RED_BITS: 16GL_ALPHA_BITS: 0GL_BLUE_BITS: 8GL_DEPTH_BITS: 24GL_GREEN_BITS: 8GL_MAX_3D_TEXTURE_SIZE: 2048GL_MAX_TEXTURE_SIZE: 16384GL_MAX_TEXTURE_UNITS: 4GL_MAX_VIEWPORT_DIMS: 16384,16384GL_RED_BITS: 8GL_RENDERER: GeForce GTX 770/PCIe/SSE2GL_SHADING_LANGUAGE_VERSION: 4.50 NVIDIAGL_STENCIL_BITS: 8GL_VENDOR: NVIDIA CorporationGL_VERSION: 4.5.0 NVIDIA 376.09GPUDeviceEnabled: falseOGLEnabled: trueGL_EXTENSIONS: GL_AMD_multi_draw_indirect GL_AMD_seamless_cubemap_per_texture GL_ARB_arrays_of_arrays GL_ARB_base_instance GL_ARB_bindless_texture GL_ARB_blend_func_extended GL_ARB_buffer_storage GL_ARB_clear_buffer_object GL_ARB_clear_texture GL_ARB_clip_control GL_ARB_color_buffer_float GL_ARB_compatibility GL_ARB_compressed_texture_pixel_storage GL_ARB_conservative_depth GL_ARB_compute_shader GL_ARB_compute_variable_group_size GL_ARB_conditional_render_inverted GL_ARB_copy_buffer GL_ARB_copy_image GL_ARB_cull_distance GL_ARB_debug_output GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_depth_texture GL_ARB_derivative_control GL_ARB_direct_state_access GL_ARB_draw_buffers GL_ARB_draw_buffers_blend GL_ARB_draw_indirect GL_ARB_draw_elements_base_vertex GL_ARB_draw_instanced GL_ARB_enhanced_layouts GL_ARB_ES2_compatibility GL_ARB_ES3_compatibility GL_ARB_ES3_1_compatibility GL_ARB_ES3_2_compatibility GL_ARB_explicit_attrib_location GL_ARB_explicit_uniform_location GL_ARB_fragment_coord_conventions GL_ARB_fragment_layer_viewport GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_framebuffer_no_attachments GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_geometry_shader4 GL_ARB_get_program_binary GL_ARB_get_texture_sub_image GL_ARB_gl_spirv GL_ARB_gpu_shader5 GL_ARB_gpu_shader_fp64 GL_ARB_gpu_shader_int64 GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_imaging GL_ARB_indirect_parameters GL_ARB_instanced_arrays GL_ARB_internalformat_query GL_ARB_internalformat_query2 GL_ARB_invalidate_subdata GL_ARB_map_buffer_alignment GL_ARB_map_buffer_range GL_ARB_multi_bind GL_ARB_multi_draw_indirect GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_occlusion_query2 GL_ARB_parallel_shader_compile GL_ARB_pipeline_statistics_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_program_interface_query GL_ARB_provoking_vertex GL_ARB_query_buffer_object GL_ARB_robust_buffer_access_behavior GL_ARB_robustness GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_seamless_cube_map GL_ARB_seamless_cubemap_per_texture GL_ARB_separate_shader_objects GL_ARB_shader_atomic_counter_ops GL_ARB_shader_atomic_counters GL_ARB_shader_ballot GL_ARB_shader_bit_encoding GL_ARB_shader_clock GL_ARB_shader_draw_parameters GL_ARB_shader_group_vote GL_ARB_shader_image_load_store GL_ARB_shader_image_size GL_ARB_shader_objects GL_ARB_shader_precision GL_ARB_shader_storage_buffer_object GL_ARB_shader_subroutine GL_ARB_shader_texture_image_samples GL_ARB_shader_texture_lod GL_ARB_shading_language_100 GL_ARB_shading_language_420pack GL_ARB_shading_language_include GL_ARB_shading_language_packing GL_ARB_shadow GL_ARB_sparse_buffer GL_ARB_sparse_texture GL_ARB_stencil_texturing GL_ARB_sync GL_ARB_tessellation_shader GL_ARB_texture_barrier GL_ARB_texture_border_clamp GL_ARB_texture_buffer_object GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_buffer_range GL_ARB_texture_compression GL_ARB_texture_compression_bptc GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map GL_ARB_texture_cube_map_array GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_gather GL_ARB_texture_mirror_clamp_to_edge GL_ARB_texture_mirrored_repeat GL_ARB_texture_multisample GL_ARB_texture_non_power_of_two GL_ARB_texture_query_levels GL_ARB_texture_query_lod GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_texture_rgb10_a2ui GL_ARB_texture_stencil8 GL_ARB_texture_storage GL_ARB_texture_storage_multisample GL_ARB_texture_swizzle GL_ARB_texture_view GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_transform_feedback_instanced GL_ARB_transform_feedback_overflow_query GL_ARB_transpose_matrix GL_ARB_uniform_buffer_object GL_ARB_vertex_array_bgra GL_ARB_vertex_array_object GL_ARB_vertex_attrib_64bit GL_ARB_vertex_attrib_binding GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_vertex_type_10f_11f_11f_rev GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_ARB_window_pos GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_bindable_uniform GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_depth_bounds_test GL_EXT_direct_state_access GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXTX_framebuffer_mixed_formats GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_polygon_offset_clamp GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_shader_objects GL_EXT_separate_specular_color GL_EXT_shader_image_load_store GL_EXT_shader_integer_mix GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_array GL_EXT_texture_buffer_object GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_latc GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_shared_exponent GL_EXT_texture_sRGB GL_EXT_texture_sRGB_decode GL_EXT_texture_storage GL_EXT_texture_swizzle GL_EXT_timer_query GL_EXT_transform_feedback2 GL_EXT_vertex_array GL_EXT_vertex_array_bgra GL_EXT_vertex_attrib_64bit GL_EXT_window_rectangles GL_EXT_import_sync_object GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KHR_context_flush_control GL_KHR_debug GL_KHR_no_error GL_KHR_robust_buffer_access_behavior GL_KHR_robustness GL_KTX_buffer_region GL_NV_alpha_to_coverage_dither_control GL_NV_bindless_multi_draw_indirect GL_NV_bindless_multi_draw_indirect_count GL_NV_bindless_texture GL_NV_blend_equation_advanced GL_NV_blend_square GL_NV_command_list GL_NV_compute_program5 GL_NV_conditional_render GL_NV_copy_depth_to_color GL_NV_copy_image GL_NV_depth_buffer_float GL_NV_depth_clamp GL_NV_draw_texture GL_NV_draw_vulkan_image GL_NV_ES1_1_compatibility GL_NV_ES3_1_compatibility GL_NV_explicit_multisample GL_NV_fence GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_framebuffer_multisample_coverage GL_NV_geometry_shader4 GL_NV_gpu_program4 GL_NV_internalformat_sample_query GL_NV_gpu_program4_1 GL_NV_gpu_program5 GL_NV_gpu_program5_mem_extended GL_NV_gpu_program_fp64 GL_NV_gpu_shader5 GL_NV_half_float GL_NV_light_max_exponent GL_NV_multisample_coverage GL_NV_multisample_filter_hint GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_parameter_buffer_object GL_NV_parameter_buffer_object2 GL_NV_path_rendering GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_shader_atomic_counters GL_NV_shader_atomic_float GL_NV_shader_buffer_load GL_NV_shader_storage_buffer_object GL_NV_texgen_reflection GL_NV_texture_barrier GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_multisample GL_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_texture_shader3 GL_NV_transform_feedback GL_NV_transform_feedback2 GL_NV_uniform_buffer_unified_memory GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_attrib_integer_64bit GL_NV_vertex_buffer_unified_memory GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_NVX_conditional_render GL_NVX_gpu_memory_info GL_NVX_multigpu_info GL_NVX_nvenc_interop GL_NV_shader_thread_group GL_NV_shader_thread_shuffle GL_KHR_blend_equation_advanced GL_SGIS_generate_mipmap GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_slice_accum GL_WIN_swap_hint WGL_EXT_swap_control
Mike S
Results:
Moving through 10 images right, then left:
- 2015.4 = 23s
- 2015.4 (retest) = 21s
- 2015.10 = 33s
- 2015.5 (1) = 27s
- 2015.5 (2) = 28s
Develop 20 images. Splits for each set of 5:- 2015.4 = 22s, 24s, 22s, 21s
- 2015.4 (retest) 21s, 19s, 17s, 17s
- 2015.10 = 39s, 63s, 87s, 123s
- 2015.5 (1) 33s, 56s, 97s, 128s
- 2015.5 (2) 35s, 54s, 105s, 138s
I'll try rolling through a couple more updates to see if results stay the same. In the meantime, I'm curious if anyone else with this Development module slowdown problem sees improvement when rolling back to 2015.4. I've been using it for the past year, in sessions running 100's of images, and have never seen the degradation of performance that has shown up in the updates above.Rikk Flohr, Official Rep
Rikk Flohr, Official Rep
Mike S
Mike S
Times are seconds to process first 5 images, 2nd 5, 3rd 5, and 4th 5
Mask FF = all 8 processors: 26 46 80 117
Mask 3F = 6 processors: 19 35 58 83
Mask F = 4 processors: 18 25 31 43
Mask 3 = 2 processors: 26 32 35 37
Mask 1 = 1 processors: 26 27 25 27 !!!!!!!!!!!!
It seems pretty obvious that something in the way you handle multiple processors changed between 2015.4 and 2015.5. In 2015.4 no masking was required, and the time required to process image 20 was identical to the time to process image 1. To get that same result in 2015.5, all but 1 processor must be turned off.
Unfortunately, turning off all but 1 processor slows the time it takes to get anything done, and least at the start.
Its also obvious that as more processors get added, the degradation gets worse.
I believe some changes were made in 2015.10, so I'll check that next. But is there an 'acknowledged' problem anywhere on this forum that discusses the need to set Lightroom affinity?
Mihael Tominšek
I used smartpreview... but have problems with it, I guess... bellow I will post the result of my test with that.
Denyer Ec
In an ideal world, one core would be left alone for UI and one for Develop so that one can continue to work during an import/export - however I've long since developed the working habit of starting both of these operations before going to bed, as they take so long and so thoroughly tie up the machine that I can do nothing else while they're running.
Denyer Ec
In an ideal world, one core would be left alone for UI and one for Develop so that one can continue to work during an import/export - however I've long since developed the working habit of starting both of these operations before going to bed, as they take so long and so thoroughly tie up the machine that I can do nothing else while they're running.
Mike S
REPEAT OF 2015.5 FOR REFERENCE
Times are seconds to process first 5 images, 2nd 5, 3rd 5, and 4th 5
Mask FF = all 8 processors: 26 46 80 117
Mask 3F = 6 processors: 19 35 58 83
Mask F = 4 processors: 18 25 31 43 <-- best early performance
Mask 3 = 2 processors: 26 32 35 37
Mask 1 = 1 processors: 26 27 25 27 <-- no degradation
2015.10
Times are seconds to process first 5 images, 2nd 5, 3rd 5, and 4th 5
Mask FF = all 8 processors: 26 38 56 80
Mask 3F = 6 processors: 18 24 35 49
Mask F = 4 processors: 16 17 23 28 <-- best early performance
Mask 3 = 2 processors: 24 29 28 29
Mask 1 = 1 processors: 23 25 24 26 <-- no degradation
Simon Chen posted an experimental mod on the other thread I mentioned that limits Lightroom to the 'Mask F' condition, so I'll try that later today just to see if the results change.
Rikk -- can Adobe duplicate this multiple-core problem, and if so, can it be 'acknowledged' somewhere with suggested workarounds (particularly noting that, for systems like mine, the absolute worst case performance is simply starting lightroom unmasked -- the way 99.99% of the world uses the product)? That would at least help people who are currently stumbling around looking for solutions, and can't find anything official that even brings the issue up. It would also be helpful to know the conditions when it may be helpful to run all processors, vs when it might be best to only run 1. My testing was only on something as simple as applying slider presets. But import/export, building previews, brush work, etc all may exhibit either better, or worse, overall speed depending on what exactly is going on.