Lightroom: LR 4 Very slow flipping through images in the develop module

  • 3
  • Problem
  • Updated 5 years ago
  • (Edited)
Flipping through the develop module, it takes 7-8 seconds for the Loading to go away for 18mb raw files. This took approximately 1-2 seconds in LR 3.7.

I am running on a Windows 7 PC with 12GB of ram.

I have tried regenerating all standard previews and 1:1 previews and it made no difference.

An entire wedding is now taking me hours more time to post process.
Photo of Kevin Graham

Kevin Graham

  • 6 Posts
  • 0 Reply Likes
  • frustrated

Posted 6 years ago

  • 3
Photo of Rikk Flohr

Rikk Flohr, Champion

  • 1373 Posts
  • 333 Reply Likes
Standard previews and 1:1 previews are for the Library module only to facilitate fast viewing of images in Loupe and zoomed views. Each image in Develop is rendered each time it is selected unless it is in the ACR cache.

On a lesser system (Win 7 6GB of RAM), I am seeing 4 seconds on a 30 MB Raw file) when cached. Non-cached files I am seeing about 6 seconds- again on a 30 MB file. The second time I pull them in it is taking around 3 seconds.

A few things to check:

Are you running LR in 64 bit mode?
Are you enabling Lens Corrections on all your images?
Are you using a lot of Spot Removal tools?
What is the size of your ACR Cache (Edit>Preferences>File Handling>)
How much space is on the drive on which your Catalog/Images/Cache are stored?
Photo of Kevin Graham

Kevin Graham

  • 6 Posts
  • 0 Reply Likes
Thanks for the feedback Rikk.. Some responses:

I am running in 64bit mode
Lens Correction and Spot removal information isn't there as these are Straight out of the Camera.
My ACR Cache was 20GB, I have since upped it to 50GB (Didn't see a performance bump)
There's about 20GB free of space on the drive where everything is stored.

So, I'm going to clear a little more free space on that drive. I'm also going to try LR 4.1RC as I am using multiple displays, and that was an area that they did notice the performance degradation.. Worth a try..

I'll report back my findings.
Photo of jdv

jdv, Champion

  • 728 Posts
  • 55 Reply Likes
Try purging the ACR cache. Moving it to a separate volume would be ideal...
Photo of Axiom

Axiom

  • 111 Posts
  • 9 Reply Likes
wait a minute..
why isn't develop using the 1:1 preview we already generated?

that seems like a ridiculous performance hit right off the bat?!
Photo of Rikk Flohr

Rikk Flohr, Champion

  • 1373 Posts
  • 333 Reply Likes
These previews are compressed JPEG, Adobe RGB and obsolete the moment you touch anything. Why would you use them for your Raw file's rendering?
Photo of Axiom

Axiom

  • 111 Posts
  • 9 Reply Likes
not according to adobe they're not
--------------
"1:1: These previews are a 100% view of actual pixels and, like Standard previews, the Camera Raw engine processes them. When Lightroom generates 1:1 previews, it also generates minimal and standard previews, so all three are available to the program as needed."

http://helpx.adobe.com/lightroom/kb/o...
--------------
So that explanation implies (mind you) that the 1:1 previews are pixel perfect 1:1 "copies" of your original image for you to view and look at (and make changes to).

The Develop module doesn't impact the original image - it recreates your image and edits that. So now I have two renderings.

I normally don't shoot RAW any way, but that's irrelevant as lightroom's Camera Raw engine does all the work "previewing" the original be it JPG or RAW just as it does the work for the Develop module.

So the result is the same. We need a "preview" to view or modify our files - period.

Now, if Develop needs a "preview" for you to edit or - more accurately - a "temp file" to make its changes - then why not simply have what ever file type THAT is as the 1:1 preview and be done with it?

Why make two files?
Seems redundant, and definitely impacts performance.

Addendum:
yes I know any editing done on the image in the Develop module requires a "redraw" of the change - I refer to the initial "view" without changes.
ie: I should be able to flip through the develop module no differently than the library module - slowing down only when having to recreate an image I've stopped to review and edit. Switching between modules is painfully slow, so I try to remain in "one or the other"
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 371 Reply Likes
All lib previews are jpeg (lossy compressed), i.e. *not* pixel perfect - not even the 1:1 image. Raws are rendered from scratch each time in develop module (unless cached in *ram* - acr cache does not help much). Develop mode rendering is pixel perfect.

Don't get me wrong, I agree there is room for improvement here (the 2nd "vote" in this thread was mine) - I've written volumes about it in the past, but not so inclined to repeat at present. Just wanted to clarify a couple points...

My guess: The reason it is how it is is so new versions of ACR (made for Photoshop) drop easily into Lightroom. Or conversely, if you prefer to think of ACR as being made for Lightroom (which is probably a more wrong way to think about it), then so that it drops easily into Photoshop ;-}. Put another way, a develop module highly integrated with Lightroom's library module would then fit into Photoshop in a fashion akin to a square peg in a round hole - say no mo'? (Lr's develop module is a relatively thin wrapper around ACR).

Cheers,
Rob
Photo of Axiom

Axiom

  • 111 Posts
  • 9 Reply Likes
Thanks Rob that helps a bit...
Today, I hacked lightroom like a noob.

I stuffed some of the modules I don't use (book, layout, etc.) into an "unused modules" folder I made in the lightroom app folder. (I'll put em back for updates)

I saw IMMEDIATE improvement.
To the tune of trimming at least 20-30 second per image manipulation.

Then I went and rendered all 11k photos in one of my catalogs, and that helped a bit too - but it's still a 10-15 second delay flipping over from Library to Develop.

weirdly, since 70% or so of all of my images are just full highrez jpgs made from my nikon, my "acr" cache never seems to get used - but my quad core gets maxed, and only half of my 16gigs of ram are used rendering while in Develop.

I'm already aware their SQlite database structure is really really poorly implemented, and that may also be another "major" core bottleneck, but at least I've been finding work around on the net - though I cannot really say they are offering work arounds here...

So thank you for the detail above, I wish adobe would clarify that in their documentation so we are working from misinformation from the get go.

I still think though it should be one cache file per image - and not waste time reinventing the wheel every time we happen to click something *smiles*
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 371 Reply Likes
Axiom wrote:
|> "I stuffed some of the modules I don't use (book, layout, etc.) into an "unused modules" folder" ... and saw IMMEDIATE improvement".

That is disturbing, and worthy of a separate problem report. You see, loading those modules, essentially initializes some things that are *not* subsequently used (in your case), so there is a bug in one or more of the module loaders if such initialization affects other things, and that should be brought to Adobe's attention in no uncertain terms - if you can determine which module(s), that would be very helpful.

PS - I don't think the Lr database is poorly implemented. I've combed through it via SQLite client (a fair amount) and it seems pretty straight-forward to me. Maybe not perfect, but saying it's "really really poorly implemented" is just, well, wrong, in my opinion.

PPS - There *should* be a long delay switching from Library to Develop, the first time (e.g. 10-15 seconds). after that, delay for new image in develop should be no more than 2-3 seconds until sliders enabled, but could easily be several seconds for complete raw rendering (before loading indicator is extinguished). If it's taking 10-15 seconds *per image* (on average), then either you've got an underpowered computer, huge raw files, or abnormal behavior.

Benchmark: with AMD CPU (4-core, 3.9 GHz), it takes about 1+1/2 to 2 seconds for sliders to be enabled, and 3-4 seconds for complete loading in develop module (more if tons of edits...). ND300 or CG12 raw files. ND800 files take about twice as long.

Rob
Photo of Axiom

Axiom

  • 111 Posts
  • 9 Reply Likes
Hi Rob, the SQlite I've chimed about in another thread about multi user - or at least network - access of the Lightroom catalog for use say from desktop to laptop... and of course the subsequent lack of progress for this "ability".

SQlite is a poor solution for such a resource intense program such as lightroom here - and is ill suited to the task. See, it's MySQL, but, well, Lite.

The additional lightroom features such as book making and the like are nice and have their place, but we really should be able to disable those for use in a workflow that negates such features - most power user users for instance would not normally use "publish to web", or use photoshop, acrobat, etc...

While I recognize it's a great feature for the "general user", i have proof (for me) as of now that having them "active" does impact a professional workflow.

The same could be said for those wanting facial recognition... nifty feature, and I might use it, but I'd be more wanting to have the ability to turn it OFF if I don't need it, rather than have Adobe cram it down my throat... Choice.

Just wait till they intergrate the Revel "properly" too. yay.... *sigh*

In the end, I'm finding the performance of Lightroom lacking as perhaps it's trying to do too much at once whilst built on a shoddy foundation. SQlite is open source, and even XBMC struggles with it just storing info about shows and movies... But xbmc is built open, and uses open, so it's acceptable - as open. I'm paying big moolah for CS6, and 5, and 4, and 3, and damn, I've spent a lot of money over the years. o_0

Obviously I like it, and it's mainstream features - I just don't understand - from a common sense aspect - why it needs to be needlessly redundant (the preview bit), or weak in it's use of a database engine. It's like using iTunes for photos... *insert a lol here*

Adobe used to be better than this. Core features were always rock solid, and the "bells and whistles" had the glitches. Now it's the bells and whistles getting the attention - or the cloud - and the core functions are suffering.

Addendum : rob, my machine: Win 8 Pro, clean install, no driver issues.
Water cooled Phenom X4 965 @ 3.8ghz @+- 45 deg C at full tilt, in the summer,
1xHD5850 running two monitors, 1xHD5450 running my "email monitor", three 1920x1080 LG's, 16gigs ram, 1T hdd for data, 1x 160 for Win8, 1T backup with 50gig partitioned for scratch --> 4 drives total, all 7200rpm sata.
The interior of the case never exceeds 40 deg C, averages at 32 deg.
Regular defag with defraggler, no indexing, and all the other windows hooplah crap is dumbed down, blah blah.

So my gear ain't the issue lol. Sure I could fork out for SSD's but not till they have better lifespans.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 371 Reply Likes
Disabling modules has 1 impact (for me):

Lr starts up a lot faster.

That's how I know it's "loading" something. However it has *no impact whatsoever* on subsequent performance (I've tested it). If you have proof that (for you), disabling modules affects Lr performance (after startup I mean), then please, for God's sake - start a new thread about it! - it's indicative of a bug that needs to be brought to Adobe's attention.

Code that is not being executed can't affect performance, unless it's hogging ram, but that's not what's going on here.

PS - SQLite is lighting fast and well suited for a single-user desktop application: consider bottlenecks are elsewhere. Don't believe me? - try benchmarking some queries... (yes, I have). Indeed, not well-suited for multi-user/concurrent client/server system architecture...

Ya know, I have my complaints about Lightroom, and Adobe, but they are not idiots - do you really think they would have continued development using SQLite (back in pre-release/prototype days), if it was shaping up to be a performance bottleneck? - I realize one could argue that such bottlenecking came later, but my experience would not support that notion.

Lr4 is much faster than Lr3 for me in some ways, in other ways: not so much... Based on what you've posted here, it sounds like you are having abnormally slow performance.

PS - Lr4 sometimes behaves poorly for me. But, so far, it's always been short lived - if it doesn't spring back to life on it's own, a restart usually helps it get straight. If it were performing poorly like that all the time (and for some, it is), I'd consider myself a member of the other camp.
Photo of Axiom

Axiom

  • 111 Posts
  • 9 Reply Likes
you're right, SQlite is better for single user... sometimes. My experience is that it's not just text being stuffed into it- and so it can grow needlessly large.. read that other thread lol... But we'll leave that for now...

I'm in a pickle because of the removal of the modules.
When I did so, I started from scratch. I simply uninstalled, defragged, reinstalled, updated, moved the modules i dont use, rebooted.
started Lightroom with one of my (large) existing lcat files (11k images) and rebuilt absolutely everything.
Ate dinner, played the Xbox, ignored the phone... had family time for a while.

right now,
it opens bullet fast into library.
it's 10 seconds to move from library to develop. film strip scrolls bullet fast- but at super low Rez and takes 3 seconds to load the "highrez thumbs" - once I stop moving the strip (12 thumbs wide)

When an image is clicked they open to "fit" within 3 seconds. Choose 1:1 and its 5 seconds.
switch to library again and it's 1-2 seconds and a redraw of the image - filmstrip unchanged.
choose an image at 1:1 and its a 3 second wait
"Fit" is immediate. awesome
these times flex a second either way depending on image content.

scroll film strip and it behaves the same as above - but not jerky like it used to be (up till today's efforts).
LR4 is way faster than LR3 like this.

so I read your post and here we go:

put modules back.
20 seconds to start.
I don't change the image shown.
change to develop 30 seconds
5 seconds to "refresh" same image same setting of "fit"
change to 1:1 6 seconds
lower to fit 2 seconds
back to 1:1 2 seconds
film strip jerky on develop
thumbnail refresh same speed
change to library - 3 seconds
I'm still in 1:1
film strip "less jerky" - only a slight lag
3 seconds to load a new image as 1:1
1 second to change to "fit"
1 second back to 1:1

with the one main image chosen in library, mouse wheel scroll is pretty darned quick, low Rez "fit" with 1 second refresh when you finish moving
10 seconds to go back to develop in "fit"
5-6 seconds for subsequent photo choices in fit
1:1 is ten seconds
scrolling the 1:1 is so jerky you have to use the mouse "hand"

exit
move - book, layout, print, slideshow, web

delete win prefetch references for a clean start, reboot.

wait for windows to realize its a computer and settle down.

start Lightroom, same lcat.
it remembers I was in develop and reopened in 5 seconds with a "fit" image
cool actually - program loads and displays image all in 5 seconds, in develop.

change to 1:1 2 seconds
can actually scroll 1:1 with mouse only small lag
film strip back to new normal (fast and smooth)
change to library immediate
back to develop 1 second
new image 2 seconds on fit
1 second to 1:1
new image 1:1 2 seconds

so yeah

module disable worked for me
my pickle?
I have to test each one at a time to point adobe as to which is the issue...

*sigh*
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 369 Reply Likes
Good stuff / wrong thread. The only reason I tested disabling modules (by renaming the module files) was that I heard elsewhere that it improved performance significantly, which surprised me. And although I was surprised to find such a large difference in startup time (I had previously assumed (wrongly, I now know. actually I was told that by people with decorated names who are supposedly experts, yet often disseminate misinformation) those modules were not, in any way, being loaded until first use), it did have no impact on performance, thus I re-enabled them. So, you are not alone, but you may be in a minority. So, report it! (in a new/dedicated thread), whether you have time to isolate to module(s) or not!!
Photo of Axiom

Axiom

  • 111 Posts
  • 9 Reply Likes
Hi Rob, it's been good chatting with you - as of now, i did add to another thread about modules specifically, but this too is the right thread for this -
flipping through the develop module is very slow - disabling unneeded modules - for me, it did the trick.
Additionally, our chat about the rendering was useful as well, thank you.

So (ignoring my aside with SQlite for now) it's still a valid post and may help others... removing/hiding the actual module files may help lightroom performance "in general" allowing your machine - or lightroom - to better concentrate on what you're trying to get it to do.

Lightroom doesn't use GPU, so if it's beating away at your CPU and ram for other things, it for sure won't be timely in generating anything anywhere.

Mileage always will vary, but at least it's out there.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 369 Reply Likes
Hi Axiom,

Adobe scans these threads in a fashion that could easily allow for critical persons to miss these comments of yours (and mine) here. It needs to be it's own thread, if you really want to be sure it get's noticed, acknowledged, other people to add comments about it... I'm not saying it's off-topic here, I'm saying the odds that it gets the attention it deserves skyrocket if you post as new thread.

But, it's your call - since I'm not having the problem, it seems inappropriate for me to report it.

Rob
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 372 Reply Likes
SQLite performance and size of catalog should have "zero" impact on develop loading time. - the time it takes to fetch develop settings and such for one image is insignificant compared to the rest, regardless of catalog size. Some other things should be and are affected by catalog size, but develop performance should not be. If it is, then you are experiencing anomalous behavior.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 372 Reply Likes
One more thing: my Lr's ram usage "never" exceeds 3GB and is usually closer to 1GB, unless:

* I'm doing whole-catalog operations which do *not* appropriately break up work into smaller chunks - usually plugins updating custom metadata, or
* things are going to he|| in a bucket (e.g. endless loop...)

If you have ram consumption at 8/16GB (most of which is for Lr) just "tinkering" in Lr, something is amiss, Lr has a rub, and is allocating more memory than it should...
Photo of Axiom

Axiom

  • 111 Posts
  • 9 Reply Likes
I've been watching ram, and in general I'm hovering between 500mb to 1gig on my 11k lcat. But I'd like to see it load more into ram for access as I can get CPU use on my quad core to hit 60-70% while ram barely rises... Add other software and that starts to hurt Lightroom

"fetching" 20 images "plus and minus" in each direction of your open photo in your library, and maybe 10 each way for your Develop, would be a yummy feature and make things supper snappy... It could make it's cache in the background while we are editing or pausing/browsing... Just like the buffer we have on our cameras.

If we have the RAM we should be able to at least allocate that so Lightroom has breathing room - like PS.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 372 Reply Likes
Axiom wrote:
|> "Add other software and that starts to hurt Lightroom".

Really? with 16GB, there should be no noticeable impact (assuming such apps are mostly idle and therefore not stealing too many CPU cycles or contending for disk access...).

PS - I shot my wad long ago - rallying for better caching behavior..., so I'll be mostly ignoring such topics - nuthin' personal ;-).

R
Photo of Axiom

Axiom

  • 111 Posts
  • 9 Reply Likes
You may want to rephrase your PS... it's got a much different meaning in Canada ha ha

The CPU spikes are only whilst flipping through images... if there was a larger cache of them in RAM, then it would not hurt the CPU so much in general. If i have photoshop, illustrator and lightroom open and working on a project I start to lag after a while (everyone does) but photoshop has so much ram it's still smooth - illustrator remains smooth, but lightroom will get sluggish flipping through pics - it's all "disk access and cpu", no real ram use.

that said though, I haven't put it through any hard core paces yet with my module modifications... that's taking place later today.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 372 Reply Likes
There should be no such lag in Lightroom due to jerkin' it around hard for hours on end (get your mind out of the gutter :-}), and usually in my case, there is no such lag. Sometimes there is, but usually: not - i.e. works as good with a system full of other apps after hard use, as it did when first opened.

I'm in agreement with better use of ram and disk for caching/performance, but I think it's worth keeping straight which behaviors are normal, and which not.

It sounds like you are having some abnormal behavior.

PS - there are some exceptions: Dreamweaver will often take excessive bites out of the CPU when idling with files open (go figure) - close the file and no more biting (Lr speeds up). And sometimes poor Lr performance occurs when my internet connection drops out, I have no idea why, but when I exit Lightroom I realize some other things are slow too, so presumably Lr is using some lib/dll that's getting hung waiting for internet connection or something - don't really know.