Charles Dee Rice Photography

While discussing LR performance on various online message boards, I’ve put together a general set of my own recommendations and findings regarding some best practices in improving and tuning LR performance.

First, consider the preview cache.  While I don’t have any direct metrics to point to, I believe from my own experience with large catalogs, that the preview cache becomes very cluttered over time. From a more technical view, on ntfs filesystems (assuming you’re on a winblows box) become fragmented with large numbers of small file deletions/creations. Unless you regularly defragment the fs your previews are in, you’ll eventually see a performance impact.

I’m a stickler for maximum performance for three reasons I can think of —

1. I was/am an “old school” CSC major — back in my college days I spent hours pouring through assembly just to eek out a few milliseconds of performance. I contributed to the early (pre-distribution) days of the linux kernel. In other words, I was an uber-geek. I am still largely uber-geeky, and I just love to tune things. So, some of my concern over performance is just part of my personality.
2. I actually run Linux native on my hardware. I run winblows for things like LR in a virtual machine, so I’m already “one foot in the performance grave” so-to-speak, because I’m running in a virtual machine. So, any small incremental performance improvement I can make on my winblows vm, I can usually notice perceptible improvements.
3. I heard a ham radio (another of my hobbies) story a few years ago, and it stuck with me. Short version — In radio, we measure signal strength in decibels (dB). Minor improvements in transmission strength might only be measurable in much smaller units, like centibels. You use a high-quality solder connector here vs. some cheap crimp-on connector, maybe you get 1 centibel improvement. You use a better transmission line you get a couple more centibels. Etc., etc., etc… It eventually adds up and you get a whole 1-2 dB of additional signal strength, just by making a series of very small improvements. And that 1-2 dB is what and make or break a DX contact. Mathematically, that holds true (perhaps even more-so) in computers, too. You make small improvements in the right places, and you can see perceivable improvements elsewhere.

Enough rambling — here is…

A collection of my own advice for tuning-up LR:

• Store your catalogs database on fast, local disk (even RAM disk if possible – much longer discussion there).
• Store your actual media files on equally fast, local disk whenever possible, but a separate physical disk than your catalog.
• Consider your location of the ACR cache (default Documents and SettingsuseridLocal SettingsApplication DataAdobeCameraRawCache) and the data-path between your media and that device. Each time you enter the develop module for an image, (assuming it isn’t in the cache already) it will be copied from the media device to that device. You want this transfer as fast as possible.
• For my really huge catalogs (which simply can’t fit on local disk and are on my NAS), I copy or move groups of files back and forth between the NAS and local storage. For example, when I first import a batch of pictures into a catalog which contains mostly NAS-stored files, I first import them to a local disk area and do my initial editing/exporting/etc. When I’m satisfied I’ve done the bulk of my work, I simply use the folder view in LR and move the files to the NAS area. If I later need to do a lot of editing on some batch of files, I copy them (not *move* but just copy) to local disk, tell LR where they are, do my business, then delete the local copy, and finally update LR to point back to the NAS files.
• Don’t use sidecar files unless you legitimately have a need for them. The time to stat and sync the files and sync metadata changes is a performance impact, even with the newer versions of LR. If your media fs is ntfs, you’ll also start down the path of introducing fragmentation. I prefer to make my media devices read-only. Back up your database after every large edit, and every so many days, of course.
• “Every so often” (which is obviously up to you), clean house. You can do these steps for all of your catalogs at once, or certain catalogs; whatever is right for you.

My personal clean-house steps:

• Run the “Optimize Catalog” on your catalogs.
• Shut down LR (duh — but worth mentioning)
• Remove the preview cache for your catalogs. (This is the “catalogname Previews.lrdata” directory inside each of your “catalogname” directory. Just destroy the entire directory. All that should remain in your “catalogname” directory is the file “catalogname.lrcat”. If you use the Recycle-Bin to do this, empty the recycle bin.
• Defragment the fs which holds your catalogs. If using the included defragger, you’ll need to run it multiple times in a row before it finally settles on how much defragging it’s going to do for you. I recommend a third-party defragger rather than the winblows version.
• When you restart LR, it will take some time to rebuild previews when you view images. If you have a set of images you know you’ll be working with, consider just rendering 1:1 previews of them manually.

My personal general LR performance tips:

• Only view the photos you want. When you use the “all pictures” folder or other large/wide scope views, LR will start statting all the files to check for file validity, meta data changes (even if you don’t *write* sidecars automatically, it will still look to see if there are any sidecars available to *read*), etc. By keeping you active set small, you reduce the calls to your media filesystem(s) — this is HUGE performance hit over network filesystems CIFS or NFS — stats and metadata checks are expensive.
• If you are going to enter the develop module, consider which images you’ll need to develop, and “hit them all first” to get them cached before you start editing heavily. Your cache will probably hold around 10-15 raw files before it is overrun; so keep that in mind as well, and try not to keep overrunning your cache.
• Remember that export or manual generation of 1:1 previews will hit your cache, too, so again if you’ll be doing a lot of developing/editing, separating your developing from your exporting might save you some cache overruns.
• When importing, if you know you’ll be making substantial changes, consider only rendering minimal previews vs. standard or 1:1. The fewer “bad” previews you generate up front, the fewer fs updates will be made later once you start re-rendering previews. Likewise, if you make any really broad develop setting changes, consider doing the “clean house” for that catalog, then re-rendering 1:1 previews afterward.

• LR Journal
• LR Killer Tips