Lightroom/Camera Raw: ACR cache - broken? (or just not helpful)

  • 2
  • Problem
  • Updated 7 years ago
  • (Edited)
There is no perceptible difference in develop module rendering time when using cache (and there is a cache entry available), vs. completely disabling the cache (write protect the acr cache directory).

Either its completely broken, or its just not alleviating any bottlenecks on my system.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 378 Reply Likes

Posted 7 years ago

  • 2
Photo of TK

TK

  • 531 Posts
  • 109 Reply Likes
What size are your image files? I believe the smaller they are, the less noticeable the gain.

The ACR cache only stores some editing-independent information. Some say its the demosaiced image but the files are too small for that to be true. Let's say it is some information that is useful for the early rendering phase.

When you have a lot of local edits (e.g., brush strokes, spot removals, etc.) (and small image files) the gain of having a cache hit will be negligible. When you don't have any computation intensive edits, you should be able to measure (not necessarily perceive without a stopwatch) a slight speed up.

Its been a while since I last tested this, but I could definitely see a small speed up for files with no edits, even with just 6MP files.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 378 Reply Likes
12MP images. How much faster is it for you rendering minimally changed images when cached (in acr disk cache I mean, not the ram cache) vs. uncached?

Riddle me this: If I set preview size to this, then the ACR cache entry size is:
1024 - small (dont remember the number)
1440 - "proportionately" bigger
1680 - huge
2048 - medium (much smaller than at 1680, but bigger than at 1440).

Other people have notes similarly bizarre sets of numbers, that are differently bizarre for different cameras. - this cant be right...

Maybe this is a clue....
Photo of TK

TK

  • 531 Posts
  • 109 Reply Likes
BTW, I agree that the Develop module should do a better job of caching renderings / previews at least for one session.

I often get the situation where I edit some photos and switch back and forth between them in the Develop module. There will be a noticeable lag (while an old preview without the changes is displayed) until the latest version shows up.

A trip to the Library module, forcing new previews to be generated (e.g., by looking at the edited photos at 1:1) will fix this. Now I can go back to the Develop module and flip back and forth without being shown old previews. Why can't the Develop module populate the preview cache as the Library module does?

I also think it is suboptimal that there is a lag before the final 1:1 rendering is shown when I zoom in the Develop module. If I zoom out and then immediately zoom in again, the display of the 1:1 version is instant. If I wait a bit after zooming out (the image will change subtly shortly after having been zoomed out) and then zoom in there will be delay again.

The two images (zoomed out & 1:1) should be cached and not be recomputed.
Photo of TK

TK

  • 531 Posts
  • 109 Reply Likes
Rob, sorry for the delay in doing this but I finally did some quick measurements.

I hand stopped rendering times (from pressing the "right arrow" key to the "Image Loading" sign disappearing), comparing cache no-hits with cache hits (same images).

With my 6MP images, I see a ~15% speed up in rendering when the cache has relevant entries (2.5 sec. average rendering vs 2.95 sec. average rendering). No idea where the saving is made, maybe it is just the initial preview display that happens more quickly and there is no impact on the final "develop" rendering at all.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 378 Reply Likes
Thanks TK,

I'm not sure my crude testing of dev mode switching times could have detected 15% difference - I'll try something more "scientific". Certainly for me if there was an effect on export rendering time it was too small for me to measure (I was only measuring a 10-photo export to nearest second). Lee Jay once said something was *about 5 times faster* when ACR cache entry was present - not sure if he was talking about some tiny piece or total switching time... I'm pretty sure he understands the difference between ram cached and disk cached (acr).

Thanks again,
Rob
Photo of Dan Tull

Dan Tull, Employee

  • 172 Posts
  • 38 Reply Likes
At the time I first saw this topic, I didn't have data handy. However, some recent experiments uncovered an example of the benefit of the cache.

For a set of 150 5DMkII CR2 files, I was able to confirm that once in the cache, the time to walk through and wait for each to load in the Develop loupe view (in "fit" mode on a 1280 x 1024 monitor) was reduced from 400 seconds to 290 seconds or between 25 and 30 percent more quickly.

Note that I had to increase the size of the cache from its default size of 1 GB to at least 3 GB (I set it to 10, but only needed 2.5 GB) to hold the data required for these photos in order to see the benefits. If, for example, you were importing 16 GB of photos from a CF card and building previews (which I think will tend to prime the cache), you'd want your cache to be roughly the same size so that it can hold all the data.

Otherwise, the cache will get fully cycled and when you start walking through the photos from the beginning, the cached data for those items will no longer be available and you'll get no speedup.

From what I understand, the cache is intended for accelerating the loading of screen resolution photos in Develop. The ratio of the resolution of the monitor and the photos probably impacts how significant the savings will be.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 378 Reply Likes
Thanks for the info Dan. Using my crude testing I still can't tell that it helps me at all. I would expect to notice 25%+ but not 15%- dunno...