LR4 speed totally unacceptable

[Rhossydd]

it's NOT the bottleneck.

Did I say it was ?

My point is the larger the screen the less responsive the develop module. There's simply more data to process and move around.

[Bart_van_der_Wolf]

If the CPU is not pegged at 100%, as you show - it's NOT the bottleneck.

Are you suggesting that the fact that the CPU(s) is/are processing at increased percentages (although lower than maximum level), doesn't take time???

In the VAST majority of cases it's the disk system.

Sometimes, sometimes not. One would need to look at the data throughput there as well. And the same applies here, it doesn't need to hit the bandwidth ceiling to take time.

Cheers,
Bart

[John.Murray]

Display resolution affecting peformance is a tempting target, so I decided to see if that was indeed an issue.

2 different machines - a Mac Pro (2006 upgraded 2007 MB, Dual Xeon 5355s, ATI 5770, 10GB), and Windows (Intel X79 - Core i7 3930, nVidia GTX660 Ti, 32GB)

3 different displays ranging from 2560x1440 to 1280x1024

No perceived difference in develop performance!

Thinking that the video cards were possibly swamping the results, I loaded LR 4.2 on an Intel H77 board with a i5 3570K / HD 4000 on die graphics, 8GB RAM (if you are looking for a powerfull budget machine, the i5 3570k is an amazing value at a bit over $200)

Again, no difference....  

[kaelaria]

Finally someone with a clue!

[knweiss]

One of the things that seems to slow my development in Lightroom is doing lens corrections first: rotate, vertical and horizontal perspective, barrel and pincushioning. These along with vignetting and cropping would seem to be logical first steps in any workflow, but maybe there is a reason why they are so low down in the development panel.

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.

Also, ever since I started using LR I wonder why it isn't able to saturate all the 8 CPU cores of my Mac Pro during a big export to a SSD. The IO activity isn't very high either (if you're on OS X you can easily take a look at LR's IO e.g. with "sudo iosnoop" and "sudo iopattern" during an export and see the idle times). When there is enough RAM and IO bandwidth LR should be able to keep all cores busy all the time processing RAWs. However, even in version 4.2 it doesn't.

For me, I came to the conclusion that performance simply isn't a priority for the developers even though so many users are not happy with it. From the outside it even seems to me that there are low hanging fruits which are ignored. I don't like this situation but on the other hand I continue to use the program because apart from that I really like it. Maybe they know this and ignoring the performance improvement requests even makes economic sense.

[AFairley]

For me, I came to the conclusion that performance simply isn't a priority for the developers even though so many users are not happy with it.

From the latest video with M&J and Eric Chan, it seems that the developers are aware of performance and are always working on it.  At one point Eric talks about at one point in the development process (I think for PV 2012), moving sliders and walking away for 20 minutes while the computer crunched the adjustment.  So I guess things could be a lot worse!

[elliot_n]

What kind of experiences are people having with the current Camera Raw in PS?  My understanding is that it is also using similar complex algorithms as the new process ver in LR?

ACR is very slow on my Mac mini (current model, 2.7 i7, AMD graphics, 16Gb ram). After adjusting sliders it takes several seconds before the preview updates. Reducing the ACR window size on my Eizo CG275W boosts performance significantly - but it's still slow.

[Rhossydd]

No perceived difference in develop performance!

I think a lot of this depends on where you start from.
If you're starting with a very high spec machine the differences in screen size won't be so apparent as with a less well specified system.
Also I suspect that reducing desktop size when your LR library is full of high resolution previews won't have the same effect as moving from a smaller desktop to a larger one.

Certainly when I added 27" high res monitor to replace a lower res 19" monitor, with nothing else changing, responsiveness of LR3 dramatically slowed down. I don't think the change to LR4 will have changed that aspect of it's performance at all.

I'm sure someone at Adobe will know exactly what's going on here, it's been such a widely reported problem, and be working hard on improving things. However I doubt they can acknowledge their performance failing publicly.

[headmj]

I certainly did not expect my simple post looking for help to set off a posy like this.

I have done a number of things since then.  I completely restored my machine, made sure Vista was at SP2 plus current updates.  I downloaded a fresh copy of LR4 and installed on the reformatted machine.  Created a new catalog and imported about 150 primarily landscape photos.  The result was somewhat better but still way too slow.

In the last 2 weeks I purchased a new HP machine.  It contains an FX-8120 running at 3.1 ghz. 12gb of memory and windows 7 64 at SP1.  It also has a single 2TB 7200 rpm hard drive.

The new system has LR 4.2 installed on it and a fresh catalog.  Things seem to be running very well at about 3.6 speeds.  I will keep track as I use all the features.

Mike

[Rhossydd]

I certainly did not expect my simple post looking for help to set off a posy like this.

The performance of LR4 has been creating a storm since the first public beta.
I suspect the reason is that the underlying quality of what it' doing is just SO good, it's terribly frustrating not to be able to work fast with it.

[John.Murray]

I think a lot of this depends on where you start from.
If you're starting with a very high spec machine the differences in screen size won't be so apparent as with a less well specified system.
Also I suspect that reducing desktop size when your LR library is full of high resolution previews won't have the same effect as moving from a smaller desktop to a larger one.

Agreed!  Which is why I did a fresh install on the 3rd less capable machine.  All previews are 1-1 (i've never done anything else....)

[Steve Weldon]

Agreed!  Which is why I did a fresh install on the 3rd less capable machine.  All previews are 1-1 (i've never done anything else....)

Hi John -

It may be possible different functions from within the Develop Module task the system in different ways.  What functions did you test? 

Maybe those who are contesting develop performance is linked to screen size would provide us their work flow?

It's a big piece of pie to eat in one byte..

[kaelaria]

In the last 2 weeks I purchased a new HP machine.  It contains an FX-8120 running at 3.1 ghz. 12gb of memory and windows 7 64 at SP1.  It also has a single 2TB 7200 rpm hard drive.  Things seem to be running very well at about 3.6 speeds. 

Mike

Which is exactly what I told you way back at the start

[Sheldon N]

Thank you for proving my points!  If the CPU is not pegged at 100%, as you show - it's NOT the bottleneck.  In the VAST majority of cases it's the disk system.

Often the limitation is how efficiently the program can access the CPU, not just whether the CPU is pegged at 100%. LR may be "fully" utilizing the CPU even though the CPU is not fully utilized.

In this case, I'm pretty sure that it's not a disk bottleneck.

[Rhossydd]

Maybe those who are contesting develop performance is linked to screen size would provide us their work flow?

On import:
Render 1:1 previews, apply copyright metadata, apply generic keywords to shoot, apply custom develop settings (apply custom camera profile, CNR 25,CNRD 50,sharpen 49,radius 1.5, edge masking 22, detail 22)
Then work the images once they're all in and rendered fully.

What puzzles me is why anyone would think screen size isn't an issue ? It's fundamental to how much data has to be processed.

As a demonstration; open LR full screen (press F) then open an image in develop. Give the image maximum screen room (kill all the toolbars except the develop panel), now make some big changes to colour temperature and notice the lag in screen updates.
Then drop from full screen and make the LR window as small as possible, then repeat the CT changes. It's dramatically faster here.

It's important to remember that some of the people that have said there isn't an issue with performance probably aren't using it intensively at all or have very different expectations of performance.

[AFairley]

What puzzles me is why anyone would think screen size isn't an issue ? It's fundamental to how much data has to be processed.

As a demonstration; open LR full screen (press F) then open an image in develop. Give the image maximum screen room (kill all the toolbars except the develop panel), now make some big changes to colour temperature and notice the lag in screen updates.
Then drop from full screen and make the LR window as small as possible, then repeat the CT changes. It's dramatically faster here.

Schewe has pointed this out in earlier threads.  My experience confirms.  On my 30" monitor with the image at maximum size available, dragging color slider all the way to left, there is a 2 to 3 second lag.  Working with the image sized to about 8x10 area on the screen, the lag is less than a second.  That's with dngs from a 16 MB sensor.

[Steve Weldon]

What puzzles me is why anyone would think screen size isn't an issue ? It's fundamental to how much data has to be processed.

I don't know.  Every time I think I've got LR figured out I find out it behaves differently than you'd expect at a certain point in the work flow or even a different brand/model of hardware can throw a wrench into things.  I wouldn't be surprised to later learn Adobe's LR team has been fighting the code throughout until the breakthrough they haven't yet experienced..   I hope to see at least 2-3 different sets of work flow vs. screen size performance degradation, maybe something will pop out at us.  Thanks for providing yours.

[Rhossydd]

I wouldn't be surprised to later learn Adobe's LR team has been fighting the code throughout until the breakthrough they haven't yet experienced.. 

There does seem to have some improvement with the recent updates.
I doubt we'll see anything really dramatic until (if?) someone at Adobe manages to utilise the currently unused power of GPUs for processing, as they did so successfully in Premiere Pro CS5.

[Bart_van_der_Wolf]

What puzzles me is why anyone would think screen size isn't an issue ? It's fundamental to how much data has to be processed.

Puzzling indeed. LR being an application that does parametric updates to the final image display (on screen or at the ultimate output size), it should be obvious that size matters (as do things like lens corrections). The only thing that could reduce (not eliminate) the dependency of the display (monitor) size, is that more than only the zoomed-in area of the image needs to be rendered.

Cheers,
Bart

[Steve Weldon]

There does seem to have some improvement with the recent updates.
I doubt we'll see anything really dramatic until (if?) someone at Adobe manages to utilise the currently unused power of GPUs for processing, as they did so successfully in Premiere Pro CS5.

I'm thinking something deeper, probably related to the kernel and memory usage.  And possibly related to other installed/used programs via the registry.

As we go through these threads we run across different areas of hardware, different work flow, and different users who swear these hardware areas make significant differences while others swear they make no difference at all.  You have those saying the fastest SSD's over slow HDD's make no difference.. regardless of the raw data speeds of each and their capabilities.  Then you have those saying more than some set amount of RAM made a huge difference, and those who swear it doesn't.  Then those who say faster GPU's have made a difference on that lag issue despite the extended GPU areas not being utilized.. and now we have those saying screen size makes a difference and those who say it doesn't.

Something is amiss.  I'm included in the above and I can duplicate what I claim but others weren't able to.  So I have no problem believing others can duplicate what I can't.  Meanwhile none of it is making sense IF and assuming the program is working conventionally.  I think the answer is it isn't.