thumbnail performance & preloading

  • 3
  • Idea
  • Updated 1 month ago
Scrolling through a catalog in grid view, thumbnail performance is normally OK. It's slower than any other produce I know of (MediaPro, Capture1, Faststone, Win10 explorer) but good enough.

However ...

Performance is only acceptable IF previews or thumbnails have been built. If they weren't built on import, or if the preview cache has been deleted (say, to clean up an SSD or fix a runaway dynamiclinkmediaserver's mess), performance is positively glacial. It can easily take 5 seconds to read a 5x7 screen of thumbnails. Even worse, there's no read-ahead, so paging through the grid (with Page Up/Page Down) takes 5 seconds for every page.

The standard remedy for this is to (re)build all the previews. But that could take literally all day with a large directory, so it's not useful for quickly browsing the contents. Even a modest directory with 10-20k images takes ages on a recent i7 desktop with SSD.

Two extremely simple steps could dramatically improve performance:

1. Add an item to Library>Previews to build thumbnails only.
2. When in grid view, render thumbnails in the background for items that aren't yet displayed.

With either strategy, I could load a large selection, go get a cup of coffee while thumbnails build, and then scroll through the grid fluidly.
Photo of Tom Fiddaman

Tom Fiddaman

  • 61 Posts
  • 16 Reply Likes

Posted 1 month ago

  • 3
Photo of Jerry Syder

Jerry Syder

  • 284 Posts
  • 139 Reply Likes
I've been meaning to make this request for some time now so thank you! Exact situation - I deleted previews some time back to release disc space but often, I need to scroll through(for too many reasons) and it takes several seconds to display the thumbnails. A 'generate minimal preview' option would be welcomed. 
Photo of John R. Ellis

John R. Ellis, Champion

  • 4377 Posts
  • 1160 Reply Likes
"If they weren't built on import..."

The import options Build Previews: Minimal and Embedded & Sidecar already provide this functionality for importing.  The setting Preferences > General Replaced Embedded Previews With Standard Previews During Idle Time controls when standard previews are built in background.

On my configuration, with these settings I can import 1200 raw photos and immediately begin scrolling the thumbnails quickly.

But these options aren't available for the other use case, deleting the preview cache.
Photo of Tom Fiddaman

Tom Fiddaman

  • 61 Posts
  • 16 Reply Likes
Unfortunately, I'm mainly concerned with the second use case. But even in the "import" case, I find it not quick, at least when the sizes increase to 10,000 or 20,000. (It's even worse if the dynamiclinkmediaserver gets involved in indexing incoming video content, but that's a separate problem.)

Simply making the "minimal" option from import available on the Library>Previews menu would be a nice start though.
Photo of Tom Fiddaman

Tom Fiddaman

  • 61 Posts
  • 16 Reply Likes
Here's my simpleminded but effective workaround for this problem:

- Get autohotkey, an open source utility that lets you script keyboard and mouse commands
- Create the following script, mapping <control><pageDown> to a series of page down operations, 30 seconds apart:
^PgDn::
Loop, 100 {
Send, {PgDn}
Sleep, 30000
}
- Run this script, bring lightroom to the front, switch to grid view, and activate <control><pageDown>

The script will then slowly page through all the thumbnails in grid view, forcing them to build. Take the dog for a walk, shoot some pictures, and when you get back, you can scroll through your stuff quickly.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4366 Posts
  • 1160 Reply Likes
Does this do something different from Library > Previews > Build Standard-Sized Previews?
Photo of Tom Fiddaman

Tom Fiddaman

  • 61 Posts
  • 16 Reply Likes
When I tested (a bit hastily), building standard previews was going to take an eternity. I think this is faster because it builds thumbnails only, or maybe minimal previews. I haven't really tested that thoroughly though.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4366 Posts
  • 1160 Reply Likes
Interesting, I did a quickie test and observed the same thing. After deleting Previews.lrdata, I scrolled through all the thumbnails and then did Build Standard-Sized Previews.  That still took a long time, indicating that building the thumbnail happens asynchronously (and faster) than building standard-sized previews.
Photo of Tom Fiddaman

Tom Fiddaman

  • 61 Posts
  • 16 Reply Likes
I'm glad you can confirm that - otherwise I'd feel a bit silly for going to all the trouble. Autohotkey is kind of cool in general though - glad I discovered it.
Photo of Tom Fiddaman

Tom Fiddaman

  • 61 Posts
  • 16 Reply Likes
Actually, I'm coming around to thinking that this doesn't work ... it may be asynchronous and therefore faster, but I'm still getting a big preview db in .lrdata. It may be that the only way to do this is to delete the preview cache, set the default size small, rebuild previews, then restore the preview cache to whatever is normally needed.