LR3 "Extra Processing in Develop" Performance Problem

i have been investigating specific lr3 performance problem.  may explain small subset of problems people have reported in "why lr3 slow?" thread.   i'm starting thread focus on particular problem.  hope others confirm/refute/refine findings.

 

the problem

 

in develop, when make adjustment, following happens: cpu usage (as shown in activity monitor's bar graph) jumps between 50 , 75% 4 cores, updated image appears, , cpu usage settles down.  happens in less half second.  note: image @ fit size.  however, instead following after adjustment: cpu usage jumps 50 75% 4 cores , updated image appears usual, however, instead of settling down, cpu usage jumps 90 100% cores , stays there 3 5 seconds before settling down. appears lr doing kind of "extra processing" since lot of computation happening after updated image has appeared.  refer problem "ep".  obviously, when getting ep, editing in develop becomes balky.

 

dependency on ratio between image size , displayed size

 

it appears ep happens when displayed size of image (in fit zoom level , perhaps fill zoom level) above percentage of actual image size (as cropped).  evidence: when editing full 21mp 5d2 images, don't experience ep.  if crop 5d2 image significantly, can ep.  when editing 10mp images canon s90, ep landscape orientation pictures not portrait orientation pictures (since in fit mode, landscape images display @ higher zoom level portrait images).  if getting ep, can eliminate sufficiently reducing size lr displaying image resizing lr window smaller, opening additional panels (i edit right panel open), displaying toolbar, etc.  appears ep enabled when displayed image 50% or larger w.r.t. actual image (as cropped).  example, ep becomes enabled when 3648 pixel wide s90 image displayed @ least 17 , 7/8 inches wide on 100 ppi monitor (i.e. 1787 pixels).

 

dependency on how adjustment invoked

 

even when displayed image size large enough w.r.t. actual image size enable ep, whether on given adjustment depends on how invoke it:

- if click (i.e. press mouse button down , release it) on track of 1 of sliders (a technique use make big jumps), ep happen.

- if press mouse button down on slider handle, drag new position, , release mouse button), ep happen

- if press mouse button down on slider handle, drag new position, continue hold mouse button down until displayed image updated, ep not happen (either before or after release mouse button).

- if highlight numeric field @ end of slider , use arrow keys (possibly along shift) increment or decrement value, ep not happen.

- ep happen if resize lr window such displayed image size above threshold.  (in fact, determined threshold making series of window width increases until saw ep indicated cpu bar graphs.)

- ep can happen local adjustment brush applications, sliders, depends on how perform brush stroke.  single click , drags immediate mouse release cause ep, drags delayed mouse button release don't.

- clicking earlier history state causes ep

- more exploration done.  example, haven't looked @ graduated filter , spot removal adjustments.

 

my theory of what's happening

 

with lr2, understanding in develop mode when displayed image below 1:1 zoom level, after adjustment invoked, lr calculates new version of image display using fast, simplified algorithm doesn't include more computationally intensive adjustments sharpening , noise reduction (and perhaps works on lower rez version of image multiple sensels binned together?).  appears in conditions described above, lr3 calculates initial, fast image update , goes on full update of image, including computationally intensive adjustments.  evidence:   setting sharpening amount , luminance , color noise reduction 0 eliminates ep (or reduces amount of time takes barely noticeable).  i'm not sure whether displayed image updated results of processing.  think answer yes since when tried adjustment of changing sharpening amount 0 90, initial update of displayed image showed sharpening after ep, displayed image updated again show different sharpening. perhaps adobe felt useful see more accurate version of image when @ or above 50% zoom.  maybe ui supposed cancel ep if start make adjustment before has completed canceling doesn't happen unless invoke adjustment in 1 of ways described above doesn't cause ep.  

 

misc

 

- ep doesn't seem happen process 2003

- others have mentioned, i'm surprised lr (both version 2 , 3) in 64bit mode doesn't use more available ram.  don't think i've seen lr go above 4gb of virtual memory or above 3gb "real memory" (as reported activity monitor) though have several gb free.

- should obvious above if experience ep, there workarounds: reduce size of displayed image (e.g. window resizing), invoke adjustments in ways don't cause ep, turn off sharpening , noise reduction until end of editing image.

 

system specs

 

first generation intel mac pro 2 dual-core cpus @ 2.66 ghz

os 10.5.8

21gb ram

acr cache on volume striped across 3 internal sata drives

lr catalog , raws on internal sata drive

30" hp lp3065 monitor (2560 pixels wide)

nvidia geforce 7300 gt

 

 

forgot say:

 

i'd appreciate people confirming whether happens them.  if edit largish images on smallish monitor, you're less see it.  test, figure out how many pixels wide , tall image displayed when you're in develop.  set crop image resulting width , height less twice values.  see if develop bogs down when click on slider track.  thanks.

More discussions in Lightroom Classic CC

adobe