ACR version 9.2 solves an old performance issue.

[Redcrown]

Back in February I reported on a performance issue with ACR 8.7 on Win7 systems with CPUs that support AVX/AVX2 (a large number of users). ACR conversion of raw to anything (jpeg, tif, PSD) was much slower than with 8.6 or prior versions.

(http://forum.luminous-landscape.com/index.php?topic=97727.0)

I continued to test each release of ACR, including 8.8, 9.0, and 9.1, and they each showed the same issue. On my system at least. Never could get anyone to confirm.

Yesterday I found ACR was at version 9.2. Loaded it and Eureka! The performance issue has disappeared. In fact, ACR 9.2 is significantly faster than any prior version.

A test that took 56 seconds on ACR 8.6 took 79 seconds on 8.7 through 9.1. Now on 9.2 it takes only 44 seconds. Apparently a proper implementation of AVX/AVX2 makes a big difference. Or maybe Adobe simply disabled their bad implementation of that feature.

I also noticed increased performance in HDR merge functions. The initial load of a bracketed set of raw files is faster, switching alignment and deghosting on and off is faster, and the final output of a merged dng is faster.

[Redcrown]

Some bad news to go with the good news...

ACR 9.2 is forcing a complete re-cache of the thumbnail database used by Bridge.

When you point Bridge at an old folder of images that were cached long ago under a previous version of ACR, Bridge re-caches everyting in the folder.

This is regardless of the file types. Tifs, jpegs, PSDs, CR2s, NEFs, DNGs, Bridge re-caches them all.

There is a long history of re-caching problems with Bridge and ACR. This is just another chapter. Why ACR somehow affects Bridge's ability to recognize whether a non-raw image file is new or old is quite a mystery.

An image file has a date/time stamp. If that image date/time matches the date/time of the cached thumb, no need to regenerate the thumb. But I suspect that Bridge is using ACR to retrieve one of the date/time stamps, and getting the other date/time stamp from the OS. Those two dates are probably stored in different formats (32bit vs. 64bit floating point?) and quantization or rounding errors result in differences of a fraction of a second.

Older problems of Bridge re-caching were system dependent. A few people suffered the issue, many did not. It was never determined why that was, but I suspected it was a factor of system speed. Faster CPUs vs. slower CPUs. Would appreciate hearing if any others are seeing re-caching now with ACR 9.2.

[Tim Lookingbill]

Have you checked Bridge's thumbnail generation preferences and Path Bar window view where it offers dropdown menu for "High Quality Thumbnails On Demand" which I have selected to stop the constant thumbnail regeneration every time I click on a folder of images in ACR 6.7 CS5 Bridge.

Just a suggestion. I don't know what menu items and preference selections have changed in newer Bridge versions.