# SLR Lounge Performance review LR4 vs LR5



## clee01l (Aug 10, 2013)

Interesting conclusions

http://www.slrlounge.com/lightroom-lr5-lr4-hardware-performance-test-review


----------



## DaveS (Aug 10, 2013)

Not that the average user is going to have a dual processor (not to be confused with dual/quad cores) at their disposal anyway.  But interesting article none-the less... Thanks for posting it.  Makes for interesting reading.


(edited: because I don't yet have a cure for fat fingers :mrgreen:.)


----------



## Jim Wilde (Aug 10, 2013)

My testing results show the opposite, LR5.2RC is faster that LR4.4 in both of the timed tests, i.e. Preview Rendering and Exporting. I've dropped a comment to that effect on that article.


----------



## Victoria Bampton (Aug 11, 2013)

My tests don't agree with that review either.  There's a lack of detail which is making it tough to know why he's getting those results.


----------



## ukbrown (Aug 12, 2013)

Can something feel faster and be measured slower.  5 feels faster than 4 to me, quite shocked by the conclusions


----------



## DaveS (Aug 13, 2013)

So, having downloaded and played with RC5.2, i have to agree with the people here.  It's definitely faster than 4.x was.


----------



## Linwood Ferguson (Aug 14, 2013)

DaveS said:


> Not that the average user is going to have a dual processor (not to be confused with dual/quad cores) at their disposal anyway.


 Core or processor in this case is similar, I've found the same kind of effect, Lightoom spends too much time in a single thread.  For example, building a library of 1:1 previews in a 8 core system it's very hard to gt over about 13% CPU, or one core.   I've also tried starting multiple builds at the same time, to no real effect.  I think there's some code out there which is single threaded.  So I took their advice, and looked for fast clock speed on my last upgrade, and it did help proportionally.


----------



## DaveS (Aug 14, 2013)

The problem with dual processor (which I think they did use) (not multi core which most of us have) boxes is when running a single threaded app, they typically can only use half the memory effectively. So given an app that likes memory, and really only uses one core, you can get performance that doesn't meet up with what you might expect.   like Ferguson, my latest box has a fairly fast clock speed, and it will boost it's core speed to somewhere around 3.9GHz when doing a single threaded app.   For me, lightroom moves along very nicely.   Definitely faster than my old 2.4 GHz box could ever hope to do.


----------



## Jim Wilde (Aug 14, 2013)

Not sure I go along with the "only uses one core" theory. This is a snapshot from Task Manager while rendering 1:1 Previews this morning:



I should point out that catching the snapshot just as 100% of the CPU was being used was slightly fortunate as overall usage fluctuates between 30% and 100%, but averages well over 50%.

But getting back to the SLR Lounge's article, and their contention that LR4 is faster than LR5, I have been doing a shedload of testing over the last few days and now have a lot of data which I need to work out how to present....hopefully later today. I have concentrated on the easier things to measure, specifically previews and exports, though I'm also going to try to (subjectively) compare image loading times into Develop.


----------



## Victoria Bampton (Aug 14, 2013)

Jim Wilde said:


> I have been doing a shedload of testing over the last few days and now have a lot of data which I need to work out how to present....hopefully later today. I have concentrated on the easier things to measure, specifically previews and exports, though I'm also going to try to (subjectively) compare image loading times into Develop.



Great job Jim!


----------



## sizzlingbadger (Aug 15, 2013)

Here is a snapshot of CPU usage building 1:1 previews on my Macbook.


----------



## Linwood Ferguson (Aug 16, 2013)

Jim Wilde said:


> Not sure I go along with the "only uses one core" theory. This is a snapshot from Task Manager while rendering 1:1....  but averages well over 50%.



I'd love to know how you get that much CPU consumption.   Mine is attached.  I selected an older folder with 250 or so images, and started a build 1:1, and it steadied out looking like the attached (it started much higher but I think it was doing things for thumbnail previews).

Incidentally, I have SSD for all the previews, scratch, system - everything but the image and library itself.  You can see the very low disk time percentage, I'm definitely thread-constrained on CPU.  And I have plenty of memory.


----------



## ukbrown (Aug 16, 2013)

I get nothing like that, i get sawtooth display, one peak for each photo topping out at 90% and my disk looks very similar to yours


----------



## Jim Wilde (Aug 16, 2013)

Ferguson said:


> I'd love to know how you get that much CPU consumption.   Mine is attached.  I selected an older folder with 250 or so images, and started a build 1:1, and it steadied out looking like the attached (it started much higher but I think it was doing things for thumbnail previews).
> 
> Incidentally, I have SSD for all the previews, scratch, system - everything but the image and library itself.  You can see the very low disk time percentage, I'm definitely thread-constrained on CPU.  And I have plenty of memory.



Have you tried disabling Hyper-threading? I did on my system when LR4.3 was released as something went wrong there and things like preview rendering started to take longer with HT enabled. Also, you say you're not disk constrained but if the image library is on a standard 7200 rpm drive then that may influence things (especially if it's externally connected).


----------



## Jim Wilde (Aug 16, 2013)

Further to my post #9 above, I've now finished documenting the performance testing that I've been running this week. The main conclusions are as follows:

The main finding is that in almost every test that I ran, LR5 (specifically the 5.2 Release Candidate) did indeed outperform LR4 (version 4.4). In some cases the improvement was only marginal, although in others (notably where Luminance NR was used, or when doing exports to smaller sizes) the improvement was much more obvious.

In conducting these tests I also noted the following:

-        When ACR cache entries exist, and are on the same fast local storage type as the catalog, there is no *performance* benefit when using Smart Previews. On the contrary, there was some evidence that they may in fact have a small negative impact during image loading into the Develop module (although this seems logical to me). I would expect, however, a different result in other setups such as when using DNG files with Fast Load Data on slower storage such as a NAS, or when ACR Cache entries don't exist.

- When Luminance Noise Reduction is used, LR5.2 RC would seem to process it more efficiently than LR4.4, both in 1:1 Preview Rendering, and Exports.

- There is some evidence that thread utilisation when Hyper-Threading is enabled has slightly improved in LR5.2 RC, though performance was still better with it disabled.

A major caveat is that these conclusions apply to the tests that I ran *on my particular system only.* Other users may experience different results.

The full document is available here: Lightroom Performance Testing


----------



## DaveS (Aug 16, 2013)

Well Jim, that's a very nice piece of detective work if I ever saw one.  You really should work for one of those computer test and analysis companies.     The small pixel dimension performance issue (clearly fixed in LR5+) is quite dramatic in those tests.

It does  agree with the indications that a number of us have that LR5 is faster for the most part than LR4.x was.


----------



## Linwood Ferguson (Aug 17, 2013)

Jim Wilde said:


> Have you tried disabling Hyper-threading? I did on my system when LR4.3 was released as something went wrong there and things like preview rendering started to take longer with HT enabled. Also, you say you're not disk constrained but if the image library is on a standard 7200 rpm drive then that may influence things (especially if it's externally connected).



I will.  I actually thought I had, I think it came back with the last bios upgrade.

The image library is on an internal raid-1 drive, but it is rotating media not SSD.  However, if it were a constraining factor you'd see a higher disk wait time I think.


----------



## Linwood Ferguson (Aug 21, 2013)

I wanted to followup on the hyperthreading comment.

I went back and disabled it (again, I think a bios upgrade brought it back).  This significantly changes the CPU utilization GRAPH, but in terms of rough timings of rate of completion I see no difference.

This is not inconsistent with how windows does its CPU loading.  I'm not certain of this, but I believe that it checks each core separately as it polls to see if it is busy.  So if you have 4 cores with hyper-threading, you need 8 continuously running threads to show 100% busy.  If you have 4 cores with hyperthreading off, you need only 4 threads running continuously to show 100% busy.  But since each core time shares its availability in hyperthreading, if you have these same 4 threads running continuously, windows will show 50% busy even though it is using 100% of its computing capacity.  At least that's what I have observed.

Meaning that hyper-threading on gives misleading results in low-active-thread count environments.  

I believe firmly that most applications (databases in particular) run better with hyper-threading off.  I believe it of lightroom also.  But in some ruch measurements of preview build time, I don't see that it made much difference if any. 

Incidentally, notice the low disk time.   I'm now about 10 more minutes into the same preview build, the disks are now at 2%, 0%, 0%, and 0%.  I.e. disk activity is very low, preview build is almost entirely CPU limited.


----------

