Hi Rob,

Since I use DNG with fast load data embedded the ACR cache seems to be used much less.

That is a new LR4-feature.

Cornelia

Hi Cornelia,

Right - I had forgotten about that. I wish they would have allowed non-DNG users to take advantage of that technology too, but since I don't use DNG, I wonder what the deal is in my case.

Rob

And my largest is only 3.9 with an overwhelming majority closer to 500k. 12mp .arw raw files. All over the map from 99k to 999k for 95% of them.

I was used to seeing cache entries in the 17mb range for my circa 25mb raw files. However a few days ago I purged my ACR cache, deleted my preview cache, then rebuilt 1:1 previews. Checking on the cache this evening I was surprised to find average cache entry size well below 1mb, probably about 400k. Just ran a quick test:

Copied 9 raw files, all more or less identical night shots (around 25mb each, hardly any variation) to my desktop. Then imported 3 each into LR2, LR3, and LR4, then checked the cache.

For the 3 LR2 imports, the cache entry was 17,404kb for each one, no variation

For the 3 LR3 imports, the cache entries were 497kb, 942kb, 942kb

For the 3 LR4 imports, the cache entries were 1218kb, 932kb, 327kb

Go figure. I have no idea of the significance of the huge difference between LR2 versus LR3&4.

To know whether this cache change improved things, I would recommend purging the cache, then do some operation to an entire directory of images (I chose to change sharpening by one unit) and then tell it to regenerate previews.  This will cause it to access every image in the directory and will rebuild the cache for that directory... If you don't cause it to rebuild the cache by doing some operation that causes it to recache everything, then it will be hard to know whether things are slow just because it has to recache every RAW file on each access or because you have some other issue.

Render 1:1 previews. It does the cache also

I've been complaining about this for years - it's how Lightroom has always worked.

The develop module shows you, if not cached in ram, but cached on disk (ACR):

1. The present Library preview: good.

2. An initial develop view based on the cache: bad.

3. A final develop view: best.

If I had my way, it would just skip phase 2 altogether, unless there is no library preview avaliable.

Better still, invent a disk caching scheme that does more good - ACR caching makes for only very minimal performance improvement, at best < 15%.

Note: if cached in ram, then it's lightening fast.

Rob

Try hitting the "Choose" button in your preferences and then choosing the folder that you want your cache kept in. I did that and that folder started filling up as I brought various raw files up in the Develop Module.

Hal, thanks for the comment.

I did select "Choose" before I posted and again after reading your message (just to be sure), but nothing at all is being written to my cache folder, even after editing images. These are all DNG files.

Are you on a Mac or PC?

Lou,

I'd be very interested in the results if you benchmark improvements resulting from fast-load data.

Rob

Sounds like there has been some significant new handling of ACR cache. It used to only be used in develop module (or exports) - big entries written (or read) when switching to develop view, or creating 1:1 previews using Library menu, but otherwise never created in Lib module.

Now it's creating much smaller files, when browsing in Lib module too...

How about one of you go-getters mastermind, benchmark, and report, eh?

Thanks for the update Lou.

How long does it take to get a finished develop view with fast-load data disabled?

Lou Dina wrote:

 

1: Sometimes when I navigate back to a previously cached image and click on it again, it comes up sharp instantaneously...

 

2: In the Develop module, a previously cached image (or one where I created 1:1 preview manually) will immediately come up sharp at 1:1 magnification, but then it gets fuzzy  for 2-3 seconds while the little hour glass spins, and returns to being sharp again. That's crazy. I am not sure what is going on, but wanted to report back on what I am finding.

See 8 posts up for the answer to these questions (1: its cached in ram, 2: lib preview - crude dev rendering - final dev rendering).

Rob

Hi Lou - no way to speed it up that I know of, and thus I complain too...

How much of a speed-up are you getting from the fast-load data? Anybody else noted a difference with/without fast-load data?

Rob

Hi All,

I have exactly the same problem that Lou had . NO writes to the cache at all. I've purged the cache, set it to 50Gb, chosen a location on a different local drive to the catalog and images, made changes to 150 DNGs with fast load data, re-written 1:1 previews for those 150 files and still no writes to the cache.

This has only been happening since I installed the trial, prior to that, with the same set-up, I had LR4beta installed and it was writing to the cache as it always had done with 1,2 and 3! I didn't uninstall the beta before installing the trial.

Nex step going to try to re-install and see what happens!

Intel dual processor 3GHz, 8Gb RAM (max available on this motherboard) + 16Gb readyboost RAM, Win7 64bit, OS,LR and catalog on 7200rpm hdd with 30% space, cache on separate 320Gb drive 7200 rpm, DNGs on 640Gb 7200rpm hdd.

Message was edited by: paul-w - added extra info

I apologize in advance if this has already been answered, but has anybody confirmed that the cache is still supposed to be used for DNGs when fast-load data is enabled?

Lou Dina wrote:

 

Thanks, Rob. I was afraid that would be your answer.

 

"How much of a speed-up are you getting from the fast-load data? Anybody else noted a difference with/without fast-load data?"

 

I'm not sure how to answer your question. I am assuming, (perhaps incorrectly), that only the DNG images I have imported since the fast load data checkbox was checked use the fast load data and have the slightly larger file size. I am guessing that all my previously imported/converted CR2 > DNG files are slightly smaller size and do not have the fast load data built into them. How can one tell?

 

At any rate, I just imported three raw images from my 5Dmk2, and told LR4 to convert to DNG and create 1:1 previews upon import. (The import was pretty slow too). When moving between images displayed at 1:1 maginification in the Develop module, the new files (imported with fast load data and 1:1 previews) take about 1-1/2 to 2 seconds to show up sharply. Some older DNG images imported with LR3 take 3-4 seconds to show up sharply. Not very scientific. All these DNG files have a file size in the 20-25 MB range.

Hi Lou,

Since I don't use DNG, I haven't done my homework, but one way to check:

1. Enable fast-load data.

2. Make a copy of a virginal photo file (outside of Lightroom).

2. Import as new photo.

3. Check time to switch to photo after it's already been selected once in develop view, and therefore the fast-load data has been written, but select a half dozen other photos first, to assure develop module is not fetching develop view from ram.

4. check file size.

5. Disable fast-load data.

6. Re-import virginal copy of same photo again, but with different filename.

7. Check time to switch to photo after it's already been selected once in develop view, but select a half dozen other photos first...

8. check file size - it should be considerably smaller than in the previous test, since it definitely won't have the fast-load data.

The difference between times is the performance advantage of using fast-load data.

Rob

I think I've been seeing the same sort of problem as Lou for a considerable time. In fact it was slow with LR3 as well and never gave the impression that data was being saved to the cache, even though the designated folder was full of files. Curiously if I try to view the same images large inside Bridge they pop into sharp focus at large size in a fraction of a second but in Lightroom (now version 4) it takes 2-3 seconds. I'm on a new 8 Core Mac Pro with 32 Gigs of Ram and it's not really any better than on my 5 year old iMac.

I've just tried purging the cache, which I've never tried before and I've allowed up to 200 gigs of space but the drive itself has over 600 gigs of space left and the cache was only 8 gigs.

All files from my 1DsII are converted to DNG with 1:1 previews created at time of import but it just doesn't feel like that data is being properly saved. This is a catlogue that was upgraded from LR3 and I just selected all the images with the idea of rendering 1:1 previews again. For some reason it picked out 639 images from over 11,000 that needed rendering. Once that's finsihed I'll try to update DNG Previews & Metadata. I'm clutching straws here because I just don't know why it's like this.

Ashley,

I'm not finding much improvement no matter what I do. The best improvement I got was creating a new catalog from my files. Rendering new previews, clearing cache, etc, sometimes helps and sometimes it doesn't. I think most of the problem is poor coding, poor caching, poor usage of computer power and cores, probably some inefficient algorithms, etc. Why it takes 3-5 seconds for sharpening to show up when toggling the sharpening on and off is a mystery to me. I'm sure some tweaking will improve performance somewhat, but Adobe needs to address the bottlenecks at the coding level. It's sad that paying consumers have to jump through hoops to get LR4 to perform even acceptably. I have loaded LR4.1 RC1, which is also a beta release, but don't see much difference. It's much slower than LR3.6. Hopefully, they will get it right soon and address these bottlenecks.

I did a paid job today and uploaded about 75 images from my 5Dmk2. I used LR4 to upload, convert to DNG, had fast load data turned on, and had it create 1:1 previews. In the develop module, there is still an unacceptable delay when moving from image to image. Library module is fast, but develop module is slow. I have plenty of HDD space, reasonably fast drives, SSD for OS, programs and my cache, 16 GB RAM and 8 cores. It's not the fastest computer on the block, but it's no dog either. I pity the poor people with older computers.

Given some time, I hope Adobe finds a way to process these images efficiently.

Lou