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.
- 55 Posts
- 43 Reply Likes
- Frustrated, stressed
Posted 2 years ago
Rikk Flohr, Official Rep
- 4868 Posts
- 989 Reply Likes
I updated the title of your thread from CC2017 (which doesn't exist) to CC2015.10.
No where in your text description (I haven't looked at your videos yet) do you mention whether going to Preferences>Performance and unchecking the GPU box improves laggy brushes and sliders. Does it?
Also, with whom at Adobe have you engaged so far and how was that facilitated? Forum? Social Media? Direct contact?
Melissa Rios, Lightroom Support Product Manager
- 104 Posts
- 25 Reply Likes
- 55 Posts
- 43 Reply Likes
To address Rikk's comment, GPU Accel was disabled for the vast majority of the videos, as it causes strange artefacts and screen behaviour as demonstrated in video 2.
I should also add that the original videos were produced on a "Nearly Clean" windows installation - I rebuilt a new workstation from scratch to try and improve LR performance, the irony of which is not lost on me :) The installation of windows (And subsequent profiles etc) were only a few weeks old, with not much besides PS CS5, LR and web browser installed.
Rikk Flohr, Official Rep
- 4868 Posts
- 989 Reply Likes
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?
- 55 Posts
- 43 Reply Likes
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 ?
- 7 Posts
- 1 Reply Like
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
- 4868 Posts
- 989 Reply Likes
- 6 Posts
- 5 Reply Likes
- 1 Post
- 0 Reply Likes
- 110 Posts
- 36 Reply Likes
- 55 Posts
- 43 Reply Likes
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.
- 37 Posts
- 31 Reply Likes
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.
- 37 Posts
- 31 Reply Likes
- 7 Posts
- 12 Reply Likes
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
- 4721 Posts
- 955 Reply Likes
I would love to have system information from you as well. I would love to get to the bottom of this issue.
- 7 Posts
- 12 Reply Likes
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.
- 83 Posts
- 18 Reply Likes
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.
- 55 Posts
- 43 Reply Likes
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?)
- 37 Posts
- 31 Reply Likes
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
- 2 Posts
- 1 Reply Like
Rikk Flohr, Official Rep
- 4868 Posts
- 989 Reply Likes
- 55 Posts
- 43 Reply Likes
(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
- 4679 Posts
- 1797 Reply Likes
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.
- 38 Posts
- 13 Reply Likes
Rikk Flohr, Official Rep
- 4868 Posts
- 989 Reply Likes
- 55 Posts
- 43 Reply Likes
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
- 4868 Posts
- 989 Reply Likes
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
- 55 Posts
- 43 Reply Likes
Rikk Flohr, Official Rep
- 4868 Posts
- 989 Reply Likes
- 55 Posts
- 43 Reply Likes
- 24 Posts
- 9 Reply Likes
NVIDIA Quadro K1100M
- 251 Posts
- 120 Reply Likes
- 37 Posts
- 31 Reply Likes
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.
- 55 Posts
- 43 Reply Likes
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 :(
- 7 Posts
- 12 Reply Likes
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.
- 1 Post
- 1 Reply Like
System is:
Intel i7 5820K @ 4.2Ghz
24gb ddr4
Nvidia GTX 1080
Library is on Samsung EVO 850 SSDs in RAID arrray.
Brush performance and gradient adjustments are especially bad. I often use 10 to 12 circular gradients for dodge and burn and by the time I get more than 4 or 5, they become hard to manipulate or place accurately because just trying to move them takes seconds, and the refresh rate drops off a cliff.
I have disabled GPU acceleration - but overall it actually seems worse in most other situations, although it does improve the brushes slightly.
Overall, the performance of Lightroom is far far behind Photoshop for me.
Rikk Flohr, Official Rep
- 4868 Posts
- 989 Reply Likes
- 24 Posts
- 9 Reply Likes
- 4 Posts
- 4 Reply Likes
I use LR at home and at work, and specs on both systems are similar:
iMac 27-inch, Mac OS Sierra
3.4 GHz Core i7
16 GB RAM at work, 32 GB RAM at home
3TB Fusion Drive
Library is on the internal drive
Zooming to 100% results in 10-15 seconds of loading time per photo, which makes it extraordinarily time consuming to check for sharp images.
I like LR just fine, but it's slow, slow, slow. Please speed focus on speed improvements for desktop rather than adding new features for mobile.
- 1 Post
- 2 Reply Likes
- 4 Posts
- 4 Reply Likes
- 85 Posts
- 18 Reply Likes
- 37 Posts
- 31 Reply Likes
- 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.
- 37 Posts
- 31 Reply Likes
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.
- 55 Posts
- 43 Reply Likes
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)
- 6 Posts
- 5 Reply Likes
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.
- 37 Posts
- 31 Reply Likes
- 85 Posts
- 18 Reply Likes
Rikk Flohr, Official Rep
- 4868 Posts
- 989 Reply Likes
Other Windows and Mac users: Security software in use?
- 6 Posts
- 5 Reply Likes
- 4 Posts
- 4 Reply Likes
- 24 Posts
- 9 Reply Likes
- 152 Posts
- 40 Reply Likes
- 9 Posts
- 5 Reply Likes
- Only using windows defender
- 11 Posts
- 3 Reply Likes
The GPU checkbox makes using brushes/editing an individual photo faster, but there is a delay going between images. As someone that does exposure/white balance adjusts to 90%+ of my images I leave this off to make my experience faster. Wish this could be fixed so I can have both ways fast.
- 38 Posts
- 13 Reply Likes
- 55 Posts
- 43 Reply Likes
- 38 Posts
- 13 Reply Likes
- 296 Posts
- 50 Reply Likes
- 55 Posts
- 43 Reply Likes
How would I verify it's running?
- 38 Posts
- 13 Reply Likes
Config.lua flags:
Develop.AdjustMaximumThreadCount = 0.51
Its about a 3rd of the way down, under the 'Installed Plugins'
- 55 Posts
- 43 Reply Likes
- 37 Posts
- 31 Reply Likes
1:1 gives me exact feel about image, and loading is faster and slight slower slidre response does not weight ower. Than GPU gives me faster zooming, paning, and operation. Still brush (today, I will not speak for tommorow) is not that much slower.
Zooming and pannig is smooth ONLY in main window. On second monitor GPU does not make any difference and panning is jaggy anyway.
- 10 Posts
- 6 Reply Likes
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"... :/
- 37 Posts
- 31 Reply Likes
- 55 Posts
- 43 Reply Likes
- 296 Posts
- 50 Reply Likes
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)?
- 10 Posts
- 6 Reply Likes
- 24 Posts
- 9 Reply Likes
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.
- 4 Posts
- 4 Reply Likes
- 10 Posts
- 6 Reply Likes
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.
- 296 Posts
- 50 Reply Likes
- 296 Posts
- 50 Reply Likes
- 55 Posts
- 43 Reply Likes
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!
- 24 Posts
- 9 Reply Likes
I've got all my drivers up to date, I've got the most recent version of Lightroom CC, and I've spent 3 hours with an Adobe rep directly controlling my computer trying to optimize my settings with no benefit at all.
I HATE using Lightroom, and if I could afford to use both Lightroom/Photoshop and Capture One, I would absolutely do it.
- 10 Posts
- 6 Reply Likes
- 24 Posts
- 9 Reply Likes
- 10 Posts
- 6 Reply Likes
- 24 Posts
- 9 Reply Likes
- 10 Posts
- 6 Reply Likes
By the way, I run an overclocked i5-2500k, 16GB RAM, GTX 970, SSD. Cache set to 20GB.
- 38 Posts
- 13 Reply Likes
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.
- 24 Posts
- 9 Reply Likes
- 55 Posts
- 43 Reply Likes
- 10 Posts
- 6 Reply Likes
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.
- 85 Posts
- 18 Reply Likes
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?
- 24 Posts
- 9 Reply Likes
- 38 Posts
- 13 Reply Likes
- 38 Posts
- 13 Reply Likes
- 38 Posts
- 13 Reply Likes
- 10 Posts
- 6 Reply Likes
C:\Program Files\Adobe\Adobe Lightroom
- 38 Posts
- 13 Reply Likes
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.
- 10 Posts
- 6 Reply Likes
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?
- 38 Posts
- 13 Reply Likes
- 24 Posts
- 9 Reply Likes
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.
- 38 Posts
- 13 Reply Likes
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)
- 24 Posts
- 9 Reply Likes
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.
- 38 Posts
- 13 Reply Likes
- 85 Posts
- 18 Reply Likes
- 37 Posts
- 31 Reply Likes
- 37 Posts
- 31 Reply Likes
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.
- 418 Posts
- 67 Reply Likes
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
- 109 Posts
- 36 Reply Likes
- 7 Posts
- 7 Reply Likes
- 109 Posts
- 36 Reply Likes
- 103 Posts
- 71 Reply Likes
- 109 Posts
- 36 Reply Likes
- 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
- 245 Posts
- 118 Reply Likes
- 109 Posts
- 36 Reply Likes
- 1 Post
- 1 Reply Like
Related Categories
-
Lightroom Classic CC
- 13796 Conversations
- 3159 Followers
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.
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:
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.