LR3.2 Raw Cache Behavior

Question

I just noticed the "Search LR Forum" box -) - that's welcome - thanks! When did it appear? Anyway, I wanted to consolidate the various caching observations through my experience in 3.2. I opened LR and went to the Dev module.
I first noticed it was never caching. I did some sleuthing and DOH! I had recently rebuilt / restructured my RAID volumes and not created the cache folder (in a RAID 0 volume I reserve for application temp stuff). I created it and resumed observation. Still not using it (nothing put in the new folder). I exited LR and restarted - bingo! Dat files got created in the folder.
These images take 1 minute+ to render in the Dev module (these are 21MP raws with tons of healing spots, my litmus test images). Which BTW went from a bit over 1.5 minutes to a bit over 1 minute with 3.2.
Observations:
1. Consecutive flip-flopping between two images is fast (5 secs) - apparently LR is using a memory cache inside the LR code space.
2. Jumping among non-consecutively-accessed (?! ) images still takes the original non-cached time.
3. Regardless of consecutive or not, the disk cache is not being read.
4. Image disk cache DAT file is only created / written to when a non-disk-cached image is accessed first, not upon further loading (good!).
5. The cache index is written to anytime a disk-cached image is accessed.
6. There's a fair amount of activity in the system temp volume during rendering, more than the LR cache volume which is not read from.
7. The image is re-calculated again rather than read from cache.
Suggestions:
1. Would be nice if the cache folder is not found to either warn user or if possible just create it.
2. After the cache folder is selected / created in LR, start using it immediately or warn user to exit and restart.
3. OK, the obvious, let's get the cache used and working properly .
Of course I may be getting the intended use of the LR disk cache all wrong, in which case sorry for the post.
DJ
System: Win 7 Home Premium 64-bit, Intel i7 980X @ 4.1GHz, 12GB (3x4GB), several RAID 0 & 10 volumes, dual 1920x1200 displays.

Answer 1

function(){return A.apply(null,[this].concat($A(arguments)))}
Ian Lyons wrote:
DJ-G wrote:
What about the size of the spots? I occasionally do some rather large ones, so that might factor in. Should I send the XMP file through the bug reporting mechanism even though it may not be a bug? I'd hate to waste these people's valuable time.
A spot heal amounts to one additional line in XMP
  <rdf:li>centerX = 0.040042, centerY = 0.047887, radius = 0.008478, sourceState = sourceAutoComputed, sourceX = 0.018519, sourceY = 0.054220, spotType = heal</rdf:li>
The number of lines added to XMP by a brush stroke depends on the complexity of the adjustment settings (i.e. exposure, clarity, sharpen, etc) and the length. In my example each brush stroke usually added 100 or more lines to XMP, hence the XMP file growing to more than 1MB.
Increasing the spot circle size to more than 50 when zoomed in at 100% will add to rendering time, but not normally by any significant amount. Add such a fix to an image with 50, 100 or more smaller heals/clones and all bets are off. Frankly, expecting a parametric based editor to work efficiently under such circumstances is unrealistic. Remember, the Spot Removal tool in Lightroom is intended to fix dust and other sensor based defects. For example, I've seen it used to hide some fluff that had managed to get itself on to the sensor, and for removing a bird from the sky, but not along with 200 normally sized dust spots. If an image needs that sort of work it's time for Photoshop, which is substantially quicker at healing, cloning, etc.
Sending your file in won't do any harm, but I wouldn't anticipate it resulting in an improvement any time soon. Re the limitations of Spot Removal, I'm fairly sure that Melissa and/or Julie has mentioned more than once on this forum that the emphasis is on Spot not the fairly massive edits folks are trying to obtain from this tool.
Actually that's how I "counted" my spots - through the XMP file text . I'm also very aware of my use of the healer as a clone tool work-around on occasion, so I'm happy I can use it as such and gladly pay the timing penalty.
What I don't see, covered more in your last post after this one, is any apparent use of the disk cache, other than its creation. By this I mean that once it gets created, there is no apparent read activity for an image's cached DAT file under any scenario / circumstance. This I observe through a real-time monitor on my taskbar that shows read / write activity by volume, and is backed by the fact that if not in memory cache the image rendering gets completely recalculated again taking the full time.
Again, thanks for your comments Ian. You must be tired /bored of this by now .