Ad
Ad
Ad
Pages: « 1 ... 8 9 [10] 11 »   Bottom of Page
Print
Author Topic: LR4 speed totally unacceptable  (Read 46430 times)
Rhossydd
Sr. Member
****
Offline Offline

Posts: 1965


WWW
« Reply #180 on: October 14, 2012, 03:04:27 AM »
ReplyReply

I'm thinking something deeper, probably related to the kernel and memory usage. 
Maybe, but the difference using CUDA on PP5 makes is staggering. Bring that gain to LR and not only should the develop issues be helped, but other tasks that slow users down like rendering previews on import and faster exporting might be greatly improved too.
Quote
... and different users who swear these hardware areas make significant differences while others swear they make no difference at all. 
The difficulty here is the quality of reporting and what users are actually doing with LR.
It's reasonable to assume that the vast majority of users reporting problems really are seeing issues. Those who say they're happy with the program may just not be aware of the problems. Some users may simply have lower expectations and some work so slowly they won't notice control lag.
It must be a nightmare for Adobe to diagnose what's going on with so many different hardware configurations.
For us on the edges just trying to get LR to work as best as possible for us it's difficult too. Most users can't afford to just buy the fastest everything, but have to try to assess which parts of a system are the most serious bottleneck and address those first. Right now it's looking like fast CPUs, fast drives and 'enough' memory are the keys to acceptable performance, high end graphics cards and massive amounts of memory aren't really necessary.
Logged
Jim Pascoe
Sr. Member
****
Offline Offline

Posts: 830


WWW
« Reply #181 on: October 14, 2012, 04:08:23 AM »
ReplyReply

This is a very good point! I've always wondered why lens correction isn't at the top because I agree that it is one of the logical first steps.


Perhaps for your photography, but I rarely use that panel and the crop and exposure are my first points of call. I think the layout probably has the tools first used by most people at the top.  I suppose it would be useful if one could re-arrange the tabs to suit a personal workflow.

Jim
Logged
Simon Garrett
Sr. Member
****
Offline Offline

Posts: 387


« Reply #182 on: October 14, 2012, 04:15:47 AM »
ReplyReply

Those who say they're happy with the program may just not be aware of the problems. Some users may simply have lower expectations and some work so slowly they won't notice control lag.
Believe me, when I'm processing 2000 images I really do notice control lag.  And I'm not getting any perceptable lag in LR4.2.  I'm using a 2-year-old i7-930. 

I get a 5 second delay the first time into Develop Module after running LR, and I get about a 2 second delay switching from one image to another in Develop Module. I get no perceptable delay on using sliders, adjustment brush etc. 

I'm not doubting that some people are getting performance issues, but I'm not.  I use a 12M pixel D300 - perhaps 36M pixel D800 users get more delay.   
Logged
Rhossydd
Sr. Member
****
Offline Offline

Posts: 1965


WWW
« Reply #183 on: October 14, 2012, 04:22:42 AM »
ReplyReply

And I'm not getting any perceptable lag in LR4.2.  I'm using a 2-year-old i7-930. 
and ? drives ? memory ? screen size ? what sliders do you use most ?
Logged
stamper
Sr. Member
****
Online Online

Posts: 2804


« Reply #184 on: October 14, 2012, 04:35:15 AM »
ReplyReply

Quote Rhossydd

It's reasonable to assume that the vast majority of users reporting problems really are seeing issues. Those who say they're happy with the program may just not be aware of the problems. Some users may simply have lower expectations and some work so slowly they won't notice control lag.

Unquote

I have viewed the "problems" reported in quite a few forums and I thought the reverse to be true. I think there are more than one or two that are now shamefaced because they have realised after reading the solutions they were wrong. I am not saying there weren't any problems but a beta is a beta and it is simply wrong to expect the program to work 100% out of the box. There were a lot of happy users who didn't have any "problems" because they did their homework before complaining, if at all? You yourself complained in a previous thread that it wasn't "productively fast" . How on earth do you think Adobe can improve the program based on that description?
Logged

Rhossydd
Sr. Member
****
Offline Offline

Posts: 1965


WWW
« Reply #185 on: October 14, 2012, 04:47:22 AM »
ReplyReply

You yourself complained in a previous thread that it wasn't "productively fast" . How on earth do you think Adobe can improve the program based on that description?
Quoting two words out of context isn't very helpful.

I've given very detailed fault reports directly to Adobe with the issues I've experienced with the various versions LR4, plus posted comments here with far more detail that explain what I'd consider to be 'unproductively fast' (waiting seconds for screen updates was simply unacceptable etc.).
Logged
Tony Jay
Sr. Member
****
Online Online

Posts: 2140


« Reply #186 on: October 14, 2012, 05:19:00 AM »
ReplyReply

This is a very good point! I've always wondered why lens correction isn't at the top because I agree that it is one of the logical first steps.

Not really a peformance point but put lens correction in as an import develop preset - then no need to worry about it hence.
This is what I do as part of an extensive import preset.

Regards

Tony Jay
Logged
stamper
Sr. Member
****
Online Online

Posts: 2804


« Reply #187 on: October 14, 2012, 05:22:16 AM »
ReplyReply

Not really a peformance point but put lens correction in as an import develop preset - then no need to worry about it hence.
This is what I do as part of an extensive import preset.

Regards

Tony Jay

A very good point. I feel that it should come before develop because the vignetting control should be used before lightening the shadows and I tend to forget it because it is down the pecking order. Thanks.
Logged

Simon Garrett
Sr. Member
****
Offline Offline

Posts: 387


« Reply #188 on: October 14, 2012, 06:56:42 AM »
ReplyReply

and ? drives ? memory ? screen size ? what sliders do you use most ?
A rather old SSD for ACR cache, catalog and images on a 1T drive (not especially fast).  12G RAM (though Lightroom uses nowhere near that) - can't remember the RAM speed and I can't see without rebooting.  CPU is 2.8G, not overclocked. 
Screen 1 size: 1920x1200, screen 2 size 1280x1024.  I set preview size to 2048 and preview quality to medium
I use all basic sliders lots, sharpening and noise somewhat, adjustment bruch frequently.  Most sliders sometimes.
Logged
Chris Kern
Full Member
***
Offline Offline

Posts: 126


« Reply #189 on: October 16, 2012, 01:46:51 PM »
ReplyReply

I'm thinking something deeper, probably related to the kernel and memory usage.

I don't run Lightroom on MS-Windows, but its performance on OS X seems to be significantly affected by physical memory availability.  I've noticed that even killing idle processes—i.e., other programs that were no longer actively making requests to the process scheduler—usually improves Lightroom's user responsiveness, presumably because killing a process frees up its resident memory set.  (For those of you unfamiliar with OS X, programs typically don't die when you "shut them down" from the graphical windowing system; they continue to run in the background so they will appear to launch almost instantly the next time you invoke them.)

I routinely kill coactive but idle processes when LR seems sluggish and it always helps.  I also coax the operating system to more aggressively reclaim physical memory by running the OS X purge command and this also always helps. (This is a very blunt instrument and I don't recommend it; then, again, I don't follow my own advice.)  For quite some time, a number of very knowledgeable outsiders have believed something is broken in OS X's memory management.  Apple has never acknowledged this and in fact may have fixed it in recent releases (I'm still running 10.6), but there's reason to believe memory management hasn't been working as well on OS X as it does on most other variants of UNIX—or even as well as most Linux distributions, for that matter.

Finally, a couple of comments on the issue of CPU utilization.  I used to do a fair amount of performance tuning of UNIX on fairly large machines.  Modern UNIX kernels often will appear from snapshot performance-monitoring utilities to be using all available CPU even when there is actually plenty of processing power still available because their schedulers will offer time slices to lower-priority (and eminently delayable) processes when higher-priority ones don't need access to a processor—e.g., when they block waiting for an input or output operation involving memory (including the kernel's demand-pager), access to a disk, or data from a peripheral device such as a keyboard.  It's a little more complicated with multithreaded applications because threads have constraints for scheduling that are more complex than those for heavyweight processes.  But I think it's safe to say that unless a snapshot tool shows that all your CPUs/cores are continuously pegged for a very long period (say several seconds since most tools only collect samples once a second), it's highly unlikely you are running out of processor.  I see no reason why this, at least, wouldn't be as true on Windows as on UNIX.

OS X offers an excellent profiling tool called DTrace which could be used to study Lightroom's performance in considerable detail while it is performing specific functions, even without access to source code, in the event someone out there with the right background wants to try to gather some empirical evidence.  I'm not willing to invest the time because (1) I can't fix memory management problems in OS X and (2) I can't improve LR.  I assume Eric Chan or someone else at Adobe is doing this type of performance tuning, which is why so many of us seeing a distinct improvement in the 4.2 release over the first customer ship.  But every operating system fights the application developer to some extent and there's often a limit to how much better performance you can wring out of a program without sacrificing features.  (And I, for one, can't think of a lot of LR features I'd be willing to sacrifice.)  At a certain point you either need to improve the efficiency of the operating system or upgrade the hardware.  The former is slow and difficult, but the latter is fast and easy: just add money.  And to the extent that memory is constrained, you usually don't need to add a lot of money.
Logged
hugowolf
Sr. Member
****
Offline Offline

Posts: 636


« Reply #190 on: October 16, 2012, 07:18:17 PM »
ReplyReply

A very good point. I feel that it should come before develop because the vignetting control should be used before lightening the shadows and I tend to forget it because it is down the pecking order. Thanks.
My point here was at no matter what point lens corrections are done, if they cause more than minor pixel position translations, then the resulting images tend to take longer for further edits, I don't find the lens transforms themselves take a long time, it is further work on an image after the lens corrections that takes a longer time. I use ultra wides a lot, and they aren't quite as distortion free (geometrically and chromatically) as macro lenses, for example.

I'm running an i7 with 32 GB RAM and SSD for softwware and RAID 1 HDD for images under Win7.

Brian A
Logged
AFairley
Sr. Member
****
Offline Offline

Posts: 1175



« Reply #191 on: October 17, 2012, 10:25:08 AM »
ReplyReply

My point here was at no matter what point lens corrections are done, if they cause more than minor pixel position translations, then the resulting images tend to take longer for further edits, I don't find the lens transforms themselves take a long time, it is further work on an image after the lens corrections that takes a longer time. I use ultra wides a lot, and they aren't quite as distortion free (geometrically and chromatically) as macro lenses, for example.

I'm running an i7 with 32 GB RAM and SSD for softwware and RAID 1 HDD for images under Win7.

Brian A

Because I frequently have to correct significant keystoning, lens correction and crop tool usually have to be my first corrections so I can see whether a particular image hangs together compositionally.  If so, I then turn off the corrections to make tone adjustments.  This particularly helps with local adjustments, which with corrections turned on can bring my (older) AMD quad core machine to its knees. 
Logged

JRSmit
Sr. Member
****
Offline Offline

Posts: 392


WWW
« Reply #192 on: October 19, 2012, 01:27:35 AM »
ReplyReply

Because I frequently have to correct significant keystoning, lens correction and crop tool usually have to be my first corrections so I can see whether a particular image hangs together compositionally.  If so, I then turn off the corrections to make tone adjustments.  This particularly helps with local adjustments, which with corrections turned on can bring my (older) AMD quad core machine to its knees. 
Have tried to improve speed by recreating 1:1 previews, set at high quality,  after the keystone and lens corrections? In my experience this helps the performance.
Logged

Fine art photography: janrsmit.com
Fine Art Printing Specialist: www.fineartprintingspecialist.nl


Jan R. Smit
AFairley
Sr. Member
****
Offline Offline

Posts: 1175



« Reply #193 on: October 19, 2012, 10:28:07 AM »
ReplyReply

I have a lot of programs installed on my PC, so as an experiment, I did a clean install of Win 7 on a separate drive and with a minimum program install (drivers, Acronis True Image, Lightroom and Photoshop).  I have not had a chance to really torture test, but it does seem that on the bare install the image redraws faster when making adjustments, but still shows some lag (AMD quad core, radon 7xxx card, 30" monitor).
Logged

hugowolf
Sr. Member
****
Offline Offline

Posts: 636


« Reply #194 on: October 19, 2012, 11:06:36 AM »
ReplyReply

Have tried to improve speed by recreating 1:1 previews, set at high quality,  after the keystone and lens corrections? In my experience this helps the performance.
No, how do you recreate 1:1 previews after geometric lens distortion corrections?

Brian A
Logged
Rory
Full Member
***
Offline Offline

Posts: 174


« Reply #195 on: October 19, 2012, 11:11:16 AM »
ReplyReply

No, how do you recreate 1:1 previews after geometric lens distortion corrections?

Brian A

In the menu: Library > Previews > Render 1:1 Previews
Logged
AFairley
Sr. Member
****
Offline Offline

Posts: 1175



« Reply #196 on: October 19, 2012, 12:52:11 PM »
ReplyReply

In the menu: Library > Previews > Render 1:1 Previews

Interesting idea, but it didn't make a big difference for me.  I timed the redraw lag when I entered -100 into the saturation value box, taking the average of three trials.  With lens correction off, the lag was 1.7 sec, with lens cortex on, it was 2.4 sec.  I rerendered a 1:1 preview from the file with lens correx on, and the lag dropped to 2.2 sec., so not a big difference.  Of course, the timings ar so short there's a lot of room for measurement error.  This is with DNGs from a 16MP sensor, BTW.
Logged

Schewe
Sr. Member
****
Offline Offline

Posts: 5500


WWW
« Reply #197 on: October 19, 2012, 04:54:34 PM »
ReplyReply

1:1 previews only help in Library and Loupe, not in Develop. The Develop module has to rip the raw image data when making adjustments, not the preview data. So 1:1 previews won't help in Develop.
Logged
BigBadWolfie
Jr. Member
**
Offline Offline

Posts: 52


« Reply #198 on: October 24, 2012, 07:19:06 AM »
ReplyReply

1:1 previews only help in Library and Loupe, not in Develop. The Develop module has to rip the raw image data when making adjustments, not the preview data. So 1:1 previews won't help in Develop.
I guess that's why it makes sense to have your raw or dng files on a SSD?
Logged
Rand47
Sr. Member
****
Offline Offline

Posts: 568


« Reply #199 on: October 24, 2012, 08:01:34 AM »
ReplyReply

My LR responsiveness issues are solved.  It is now instantaneous on sliders, and very fast from module to module. I tried every tweak I could find with my old hardware.  AMD quad core, 8 gigs RAM, single 2TB HDD. Nothing worked.  LR 4.2 was a little better, but with lots of cloning, lens correction, etc. the sliders lagged and I could still bring LR to a dead stop at times.

Solution.   New hardware.   i7 Ivy Bridge, 32 gigs RAM; fast video card w/ 10 bit Displayport out; SSD for OS & programs; 2nd SSD for ACR cache & scratch, catalog & previews; 2TB fast HDD for data & image files.

Handles large files like hot knife through butter.  Being able to instantly see effects of very small slider adjustments is a HUGE improvement and allows me to "finally" tap into the full goodness that PV2012 brings to the table.  

Not an optimal solution from a financial perspective, but as a practical matter my frustrations are gone and I can return to concentrating on the images themselves.
« Last Edit: October 24, 2012, 09:58:52 AM by Rand47 » Logged
Pages: « 1 ... 8 9 [10] 11 »   Top of Page
Print
Jump to:  

Ad
Ad
Ad