# Pokey LR on  Mac with SSD?



## Skrat (Jun 22, 2015)

I've dealt with this particular performance issue ever since LR came out.

I cache all of its previews on an SSD (1:1, SmartPreview, Standard)

I store the original files on an SSD

I still can't get LR to load up pictures in a 'snappy' fashion. If it clearly does NOT have it in its memory, it can take anywhere from 3-8 seconds to load up the next pic. While I wait the photo is either lego-block or quite blurry.

This is with any Mac I've used recently. MacPro with its internal  SSD, MacBook Pro with its internal SSD, iMac with a SATA SSD.

I can see watching the file activity that LR does write to private system folders as well as reading from its cache. But since it's all on an SSD (minimum speed 200mb/sec, max up to 1 gig/sec), surely it can't take so long to load up a 20, 30 or 50Mb NEF or CR2? Simple math would say it can load the photo from the drive in less than 1/4 sec. with the slowest SSD. The file preview is cached, so reading the cached bitmap should take no more than 1/4 sec too. So we're at 1/2 a sec. But it still has to wait and say 'loading...'. 

No other apps are running.

Plenty of RAM is available 'unused' (20-30%)

Lots of system space available on the SSD for memory paging in / out.

So what am I missing?

Thanks!


----------



## davidedric (Jun 22, 2015)

I am no expert, and I have never used a Mac, but I have assumed that under the covers Lightroom has to take the RAW file and transform into something that can be manipulated algorithmically, then applying any existing edits.  You haven't mentioned cpu.  What's that doing whilst the image is Loading?

Incidentally, I saw no significant change in performance when I moved my images from ssd to an internal hd, whilst leaving catalogue and previews on the ssd.

Dave


----------



## wilderw (Jun 22, 2015)

Not every Mac user experiences this but it's long been a puzzle to me why some do and some do not (I do not - neither on a retina iMac nor on a 2012 retina Macbook Pro). There are many additional details that would be needed to investigate your issue, What camera are you using, what image size in megapixels, what typical file size, raw or jpg, raw or DNG, what standard preview size and quality did you specify for your catalog, what preview choice do you select on import, what is your cache size, what is your screen resolution set to, are you seeing the issue in Loupe mode or only in Develop module, how many adjustments (global and local both) are applied to your images, what develop presets are applied on import, what are the specs on your Mac (CPU, RAM, GPU), is GPU enabled in LR 6, what differences do you see if you pre-generate 1:1 previews.

If you could upload (say 25 or so) of your typical images on Dropbox or similar, other's with Macs might see if they can duplicate your issue.


----------



## Skrat (Jun 22, 2015)

davidedric said:


> I am no expert, and I have never used a Mac, but I have assumed that under the covers Lightroom has to take the RAW file and transform into something that can be manipulated algorithmically, then applying any existing edits. You haven't mentioned cpu. What's that doing whilst the image is Loading?
> 
> Incidentally, I saw no significant change in performance when I moved my images from ssd to an internal hd, whilst leaving catalogue and previews on the ssd.
> 
> Dave




That is the problem. The CPU is doing nothing that I can see…

this is with any of the CPUs in the Macs mentioned earlier, i.e. Xeon quad/hex processors, i7s with 4 processors and gobs of RAM available etc. No other tasks are enabled. This is with Canon 5D CR2 files, Nikon 800 NEF files, Canon 5DS CR2 files etc. DNG or native RAW.

I guess ultimately the question is:

*What is Lightroom doing when it loads up NEF/CR2/DNG non-JPEG images? What's the purpose of cache files if they aren't used? *

There's no evidence that the cache files are used CONSISTENTLY. Yes, sometimes I can see and monitor that LR is accessing a cache file, but that still doesn't mean anything. 

It is totally inconsistent. Sometimes it is very zippy (with a huge and optimized catalog file) and other times with the same sets of pictures and catalogs it isn't. 

In theory I guess what Lightroom should be doing when going through Gallery/Develop mode and switching between photos which have had their standard previews, 1:1 previews and smart previews all generated is:



Load up the cached file and check to see if its status is current, i.e. last develop modifications are burned in
Display file on screen AS IS while:
Loading up the original file and confirm that the screen contents are identical to what it should render. If not:
render
write updated caches


But it does NOT do this. This is NOT CPU dependent. CPU cores are often idle when switching between photos.

Lightroom seems to do:

1) Load original file
2) Display blocky preview from Gallery mode 
3) Render image

It is blindingly obvious when the image is cached in memory, it just 'snaps' nicely to screen as I go through the photos. It is equally clear when it hasn't loaded up a cached image. I canNOT figure out a way to PREDICT or FORCE it to load/preload from cached files.

For a few pictures, not a big deal. But when going through a set of 100s or 1000s of photos, this can add many hours over the course of an edit, processing etc. It doesn't have to be this way.


----------



## Skrat (Jun 22, 2015)

wilderw said:


> Not every Mac user experiences this but it's long been a puzzle to me why some do and some do not (I do not - neither on a retina iMac nor on a 2012 retina Macbook Pro). There are many additional details that would be needed to investigate your issue, What camera are you using, what image size in megapixels, what typical file size, raw or jpg, raw or DNG, what standard preview size and quality did you specify for your catalog, what preview choice do you select on import, what is your cache size, what is your screen resolution set to, are you seeing the issue in Loupe mode or only in Develop module, how many adjustments (global and local both) are applied to your images, what develop presets are applied on import, what are the specs on your Mac (CPU, RAM, GPU), is GPU enabled in LR 6, what differences do you see if you pre-generate 1:1 previews.
> 
> If you could upload (say 25 or so) of your typical images on Dropbox or similar, other's with Macs might see if they can duplicate your issue.



Due to the size of the files involved (none less than 20Mb) and my internet connection, I cannot do this. However....


This is a problem with large RAW files. JPEGs load up quickly since they are so much smaller. It is something I have seen on all sorts of Macs, newest generation and 5 year old macs.

What is the 'zippy' way to configure LR to make it get out of my way and let me get the photos out? 

lets rephrase this:

If you do NOT experience this with your Lightroom setup and you are using 20+MP RAW/DNG files and can go through a good edit session without noticing any lag as it is 'loading image', what is the setup you use to make it go so fast? Is it fast with 50,000+ files in the catalog? or only 10,000? Preview settings? Cache? SmartPreview?

thanks !


----------



## mcasan (Jun 22, 2015)

I had over 100,000 images in my catalog and finally decided to make a second one for images starting with 2014.  I put the card into my Macbook and open Perfect Photo Suite Browser.   I use it to very quickly decide which images to import.  No way all the images are keepers.  The keepers are sent to Lr for import.  Lr imports the raw file, no DNG conversion, runs the import preset that fills out the copyright info, applies a develop module preset of adjustments, and generates the 1 to 1 previews.  Once the import is done I can quickly move through the imported images and do final editing.  That is usually quick as the large previews are already generated since I am only dealing with the keepers.   The card goes back into the camera body for reformatting.  I then tell Time Machine to do a backup.


----------



## wilderw (Jun 23, 2015)

Skrat said:


> If you do NOT experience this with your Lightroom setup and you are using 20+MP RAW/DNG files and can go through a good edit session without noticing any lag as it is 'loading image'
> thanks !



Well the test I did this morning before replying to your message was to import 25 DNG files (Nikon D7100 - 24 megapixels. The DNG files have embedded fast load data and medium size previews). During import I rendered Standard size previews at Auto size (2880) and medium quality. When preview generation was complete and in Loupe mode (with side tabs enabled) I can advance rapidly from one photo to the next without delay suggesting the screen is being rendered from the preview files. This suffices for review purposes and photo culling.

If I next build 1:1 previews and go into Develop mode, I do see Loading as I advance from photo to photo but the delay is brief 1-2 seconds and quite tolerable.

I have NOT confirmed whether the behaviour above would be sustained with significantly more images nor did the test I do this morning have significant edit history attached to each image.

This was all on a 2012 retina MBP with 16GB Ram, Intel Core i7 2.6Ghz and the stock SSD 500GB drive that came with the machine. GPU is an Nvidia Geforce GT 650M

I agree completely with you that LR's handling of cache files seems mysterious and inconsistent.


----------



## Skrat (Jun 23, 2015)

wilderw said:


> Well the test I did this morning before replying to your message was to import 25 DNG files (Nikon D7100 - 24 megapixels. The DNG files have embedded fast load data and medium size previews). During import I rendered Standard size previews at Auto size (2880) and medium quality. When preview generation was complete and in Loupe mode (with side tabs enabled) I can advance rapidly from one photo to the next without delay suggesting the screen is being rendered from the preview files. This suffices for review purposes and photo culling.
> 
> If I next build 1:1 previews and go into Develop mode, I do see Loading as I advance from photo to photo but the delay is brief 1-2 seconds and quite tolerable.



Which is what I have seen as well for a small catalog and a smallish work session. If I am working with a large set of files (3-400) then the cachine/loading problem is occasionally NOT a problem, but USUALLY is.



wilderw said:


> I have NOT confirmed whether the behaviour above would be sustained with significantly more images nor did the test I do this morning have significant edit history attached to each image.
> 
> This was all on a 2012 retina MBP with 16GB Ram, Intel Core i7 2.6Ghz and the stock SSD 500GB drive that came with the machine. GPU is an Nvidia Geforce GT 650M
> 
> I agree completely with you that LR's handling of cache files seems mysterious and inconsistent.



In my experience the problems encountered are when LR is dealing with a large session. For instance, going through a year's worth of pics (maybe a few 10's of 1000's) is guaranteed to run into this despite pre-building all three caches/previews whatnot.

Where the point is where LR starts throwing up that dreaded message… I just don't know. Can't figure out a reproducible way of (a) staying within the 'cache' zone and (b) getting into the cache zone.


----------



## Jim Wilde (Jun 23, 2015)

The Library and Develop modules operate differently, so you should expect a different experience when switching between the two.

What's not clear to me from your posts is which module(s) you are having the trouble with? 

In Library, if you have, as you say, pre-rendered 1:1 previews then you should have the "snappy" performance that you are expecting....but do understand that once you have started to edit an image in Develop, that 1:1 preview is immediately discarded (because it's now wrong, right?).....and it not automatically recreated. So the next time you open that edited image back in Library you may see a slight delay ("Loading" message briefly) as a Standard preview is built....but not a 1:1 preview. So if you then zoom into 1:1 on that image, there'll be a much longer delay as a 1:1 preview is built.

In Develop, the library preview is very briefly shown, which is quickly replaced by either the Smart Preview (if it exists) or the ACR Cache entry, which remains on screen until the full raw conversion is done....which can take several seconds, depending on file size and system (CPU mainly) capabilities. There is no way to avoid this by pre-caching, Lightroom doesn't have that capability. You can move back to the previous image or two and find instant loading as those are still cached (and if you have the GPU enabled you may find a few more "previous" images are cached on the GPU), but nothing yet going forward.

So with that said, can you clarify for me where exactly you are getting the loading delays?


----------



## Skrat (Jun 23, 2015)

Thank you for the detailed response...



Jim Wilde said:


> The Library and Develop modules operate differently, so you should expect a different experience when switching between the two.



This is not entirely clear from the UI. 

Bottom line: when I go from 'Gallery' and 'Library' mode into 'full screen' or 1:1 mode BEFORE getting into the detailed Develop mode I run into this issue. I also run into it with the Develop module.

IOTW: Once the picture is NO LONGER a thumbnail in the filmstrip/light-table I encounter this caching/non-caching performance issue.




Jim Wilde said:


> What's not clear to me from your posts is which module(s) you are having the trouble with?



Any enlargement past the max thumbnail size. Once I get into 1:1 or 'Develop' mode with 'Loupe' etc.




Jim Wilde said:


> In Library, if you have, as you say, pre-rendered 1:1 previews then you should have the "snappy" performance that you are expecting....but do understand that once you have started to edit an image in Develop, that 1:1 preview is immediately discarded (because it's now wrong, right?).....and it not automatically recreated.



This may well reflect the case but it isn't a logical stream of events from where I sit. 

To my way of thinking when Lightroom switches from one image to another, the XMP / sidecar file should be updated to reflect changes and the changes written out there AND as the file is closed, the cache updated with the last current bitmap from the processing engine. Given the 'oomph' of our CPUs and data writing speeds to storage (SSD or any modern hard drive) this should hardly be a stretch of computing resources to close out a file, write a cache WHILE at the same time loading up another file and its attached bitmap screen cache. This is trivial stuff for our modern computers and OSes to do. I would be highly puzzled/surprised if this is beyond Lightroom's abilities. 

In this way, the cache is discarded when the screen bitmap no longer is the same as the cache. It's a simple matter after the user/me/whomever switches to another picture for the changes to be written out to XMP & Cache and flagged as 'latest render'. I canNOT imagine why the cache would be discarded BEFORE first loading of a picture. It must be the same as the file WAS the last time it was opened.

[Ah, the only exception would be if a 'develop setting' were to be applied to a whole selection of images… in this case, the cached previews/1:1 renders would be invalid — but this is not what I am referring to in my first post. In this case, I have rendered all three types of previews ahead of time and am still running into this 'loading…' 'loading…' problem for more than a few seconds at a time]






Jim Wilde said:


> So the next time you open that edited image back in Library you may see a slight delay ("Loading" message briefly) as a Standard preview is built....but not a 1:1 preview. So if you then zoom into 1:1 on that image, there'll be a much longer delay as a 1:1 preview is built.



I 'get' how delays can happen as previews are generated to reflect the latest changes or magnification levels. That's fine. I don't get why there is a delay if all three types of previews are pre-rendered and I am examining multiple pictures in a sequence while jumping through a filmstrip while at 'fit to screen' or '1:1' mode. The cached data is there, why isn't Lightroom using it?




Jim Wilde said:


> In Develop, the library preview is very briefly shown, which is quickly replaced by either the Smart Preview (if it exists) or the ACR Cache entry, which remains on screen until the full raw conversion is done....which can take several seconds, depending on file size and system (CPU mainly) capabilities. There is no way to avoid this by pre-caching, Lightroom doesn't have that capability. You can move back to the previous image or two and find instant loading as those are still cached (and if you have the GPU enabled you may find a few more "previous" images are cached on the GPU), but nothing yet going forward.
> 
> So with that said, can you clarify for me where exactly you are getting the loading delays?



In this case:



> In Develop, the library preview is very briefly shown, which is quickly replaced by either the Smart Preview (if it exists) or the ACR Cache entry, which remains on screen until the full raw conversion is done....which can take several seconds, depending on file size and system (CPU mainly) capabilities.



I see no evidence of any CONSISTENT behaviour by Lightroom to show that it is doing what it should be doing according to what you have written. I do have a Smart Preview cache set for the entire catalog and I do also have the ACR Cache file also created.  But it is NOT loading or touching these files. At all. Period. Often. Usually. Sometimes it does. Most often it does NOT.

Does this clarify what I am and am NOT seeing?

thank you for your help!


----------



## Jim Wilde (Jun 23, 2015)

Sorry, 'no' is my answer to you last question, as I'm still not getting a clear picture in my mind of how your system is operating. I do see consistent behaviour on both my Mac and Windows systems, so perhaps you could do a video capture of the issues that you are seeing, both in Library and Develop modules?


----------



## wilderw (Jun 23, 2015)

Exploring further today I have an observation (well speculation to offer). If I purge the raw cache and monitor the folder - no cache files are then created when I work with DNG files containing fast load data (cache files are created while working with Nikon NEF files). I wonder if it would be worth your while to convert some of your RAW files to DNG and see if your performance changes for better or worse.


----------



## Jim Wilde (Jun 23, 2015)

To be honest, I wouldn't have expected much difference between a DNG with FLD, and a proprietary Raw with an ACR cache entry....the only potential impact would concern the placement of the respective data, especially if the image files are on a slower external or network drive (in which case the DNG with FLD would be at a disadvantage).


----------



## tspear (Jun 23, 2015)

Jim,

Thanks for the explanation, I never bothered to figure it out or read on the cache system before (I know you, Cletus and others have posted the info, but I never really read it). Lr seems to work just like you describe on my Macs.
What I do not understand is why Adobe never created a caching system for the develop module. There are times when I am flipping back and forth between the library and develop modules and it would be nice if Lr rendered faster.

Tim


----------



## wilderw (Jun 23, 2015)

Jim Wilde said:


> To be honest, I wouldn't have expected much difference between a DNG with FLD, and a proprietary Raw with an ACR cache entry



File placement is not an issue for me - everything is on one SSD. The OP is noting inconsistent use of the ACR cache so getting FLD from DNG may be preferable. It's at least worth an experiment to see.

Update: So I just re-ran a comparison - 25 NEF files (24 MP), advancing image to image in Develop at 1:1 size with 1:1 previews pre-generated - and then the same 25 files converted to DNG with FLD and rebuilt previews. 

Two results: the DNGs are consistently faster to load (1-2 seconds, vs 3-4 for the NEFs). Secondly - back-tracking to previous image is immediate - going back 2 images causes re-loading. Conclusion - LR could still be more aggressive in utilizing RAM.

Unknown - whether the performance would remain consistent when actively working with a larger number of DNG files.


----------



## Skrat (Jun 24, 2015)

Jim Wilde said:


> Sorry, 'no' is my answer to you last question, as I'm still not getting a clear picture in my mind of how your system is operating. I do see consistent behaviour on both my Mac and Windows systems, so perhaps you could do a video capture of the issues that you are seeing, both in Library and Develop modules?



A video unfortunately will not make this any more clear/murky than I have already attempted to explain. 

If I am in 'Library mode' and in 'thumbnail mode', then I can cruise through all my photos without a problem.

If I choose in Library mode to double-click on the photo, I enter into the 'Quick Develop' mode. Often the photo, despite me MANUALLY building a cache of it (Smart/Standard/1:1) will display a 'loading…' alert. Not always. But often.

If I am sorting through a shoot of say 7-800 photos, with all of the previews set (smart/standard/1:1) there is absolutely NO WAY I can go through 'Quick Develop' mode and switch between photos quickly. I can do that for a few photos ± 3-4 from the start (ie. scroll back/scroll forward in the film strip), but after that, I have exhausted the in-RAM cache and have to load up the files and (judging by delay involved) re-render it. This is strange to my way of understanding the purpose behind caches and pre-rendering. To make this as straight forward as possible for the point of this conversation … this is excluding mass-application of develop settings in Library mode and then loading up the pictures.

All files referenced by LR are on an SSD. (original images and previews/caches/smart previews). No difference if it's DNG, DNG w/Fast Load or NEF/CR2. It's too easy to run out of LR's in-RAM cache when dealing with a large edit/import session.


----------



## Jim Wilde (Jun 24, 2015)

A part of my confusion is in understanding your terminology, and translating it to my terminology so that I could "see" what you were describing.

If I'm understanding correctly, all of the issues you've described in your last post are happening exclusively in the Library module, is that correct?

"Thumbnail mode" means scrolling through images in the Grid view, correct? So no problem there, as expected.

"Quick Develop mode" I think means that you've simply gone into the single-image Loupe view, correct? 

OK, so now that I think I'm on the same page as you, the symptoms you're describing are not typical. If you have pre-built 1:1 previews, moving through your images in Loupe view mode in the Library shouldn't be giving you the problems you're experiencing.....when I do that I may occasionally see a flash of the "Loading" indicator, but no kind of delay in that really.

Just as a test, select maybe 25 images in the Library module, render 1:1 previews for them, then enter the Loupe view and then use the forward arrow to cycle through those 25 images and tell me if you get any "loading" delays at all. You really shouldn't, so if you do then at least we'll have established that there's not a process misunderstanding going on between us, and we can then try to figure out what the problem actually is.

Apologies for the delay in getting to this point, but the preview system can be quite complicated to understand, which is why I really needed to understand what "mode" you were using.


----------



## Skrat (Jun 24, 2015)

I think we are nearing the same page. 

I've spent a while doing screen recordings (analog and computer-based) for the following observations:

The problem is most obvious when we are in the Library module and looking in the 'Loupe' view as I go between a 'large' thumbnail and a full-screen enlargement of whatever picture I am looking at. (Hadn't noticed it was called 'Loupe view'... now I have learned something new today  )

Note: This also applies in some parts to Develop mode if I am looking at the same picture and then choose to go forward or backward (i.e. by left/right arrow keys)…I have verified that I have generated the three cached options and I am cycling through many pictures 'to the left' and 'to the right'.

In 'Develop' mode, the delay is not as horrendous 

In Loupe Mode… yech. With a speedy SSD (MacPro 2013) and an idle CPU, I'm looking at a ~6 second wait while the picture is loaded… this doesn't sound like much, but over an editing session of a few hours, that definitely adds up.

-------Observations below are based on a subset of 12,000 RAW (21-50MP dimensions) photos  zoomed at 100% (1:1)  and timing with a stopwatch, phone video and a screen recording with film strip showing at the bottom of the screen.

​


> TL;DR: Develop mode loads up the images much more quickly than Loupe mode - average speed is 3.5 - 4.0 seconds for a picture in Develop mode and 5-6 seconds in Loupe mode.  Occasionally a cached file is hit and the switch is nearly instant, but this is often not the case



*Loupe mode:* on average it takes 5-6 seconds to switch between any randomly chosen high MP picture (20+MP - 50MP) that are triple cached (1:1/standard/smart). First portion of loading image is a simple scale up of whatever image is in memory, i.e. 'lego block super sized pixels' and then a partial load. 

*Develop mode*: on average it takes 1-2 seconds from 'click' of a random pre-cached file to final image without loading… warning. 0.8 seconds from click to the medium resolution picture and then an additional 1.3 seconds to get the final picture withOUT the 'loading…' warning. No super-low-resolution blocky previews are generated.

Occasionally we will get a cache hit in either mode and the picture will load up instantly, but often this is not the case.

​*Questions remaining:*

Why the difference in loading speed between Loupe and Develop mode? (~6 vs ~3 seconds)
Why are there random perfect 'cache hits' where pictures swap out almost instantly and other times we have to go through this incremental load process.
How do we change 'random perfect cache hits' to something more predictable and consistent?


----------



## Jim Wilde (Jun 24, 2015)

The Develop "loading delays" are normal.....the loading process in Develop is first to show the Library preview, just to give you something to look at while it renders either the Smart Preview or (if no SP exists) the ACR Cache/FLD data. When the second stage is complete the histogram will show, "loading" should disappear and the develop sliders are "released" so that you can start working the image. And while the second stage is happening, the full raw file is being rendered and will eventually (several seconds later) replace the Smart Preview/ACR Cache file.....though you'd need to look very hard to see that happening (you may see a slight movement in the histogram, for example).

Currently, the full rendered image is held in the system cache, and should stay there when you move onto the next image.....so at that point if you move back and forth between those two images you getting the full cached data, hence instant response. But it's only two.....

However, in LRCC/6 with the GPU feature enabled, LR can take advantage of the GPU RAM and can thus cache a few more.....but again only the images that you've just seen, there is no pre-caching done. I've noticed up to 8 images cached using the GPU, but it seems a bit random and I haven't figured out why yet.

Library....really this is where your problem is because you should have *zero* delay if you are sure that a 1:1 preview exists for the image you are trying to view....so I wonder if there's an issue either with the SSD or with the preview cache itself. You could try renaming the preview cache, which would then force Lightroom to create a new (initially empty) cache.....then repeat the test, i.e. select a bunch of images, build 1:1 previews, then scroll through them in Loupe mode to see if there's a difference.


----------



## mcasan (Jun 24, 2015)

Might be interesting to run Disk Warrior on the SSD (you have to do that from a USB since the SSD is the boot drive) to check all the file structures, fragmentation,...etc.     Also run Black Magic Speeddisk test to see the read/write speed of the SSD.  If the SSD is a newer PCIe connection, the read/write speeds should in the 800+ range.


----------



## Skrat (Jun 24, 2015)

Jim Wilde said:


> The Develop "loading delays" are normal.....the loading process in Develop is first to show the Library preview, just to give you something to look at while it renders either the Smart Preview or (if no SP exists) the ACR Cache/FLD data. When the second stage is complete the histogram will show, "loading" should disappear and the develop sliders are "released" so that you can start working the image. And while the second stage is happening, the full raw file is being rendered and will eventually (several seconds later) replace the Smart Preview/ACR Cache file.....though you'd need to look very hard to see that happening (you may see a slight movement in the histogram, for example).



So this is a more complicated process than the 'Loupe' mode… but it's still notably faster than 'Loupe Mode'. 



> Currently, the full rendered image is held in the system cache, and should stay there when you move onto the next image.....so at that point if you move back and forth between those two images you getting the full cached data, hence instant response. But it's only two.....
> 
> However, in LRCC/6 with the GPU feature enabled, LR can take advantage of the GPU RAM and can thus cache a few more.....but again only the images that you've just seen, there is no pre-caching done. I've noticed up to 8 images cached using the GPU, but it seems a bit random and I haven't figured out why yet.



Very random. There is no feedback or indication that it has preloaded anything. It is truly hit'n'miss.




> Library....really this is where your problem is because you should have *zero* delay if you are sure that a 1:1 preview exists for the image you are trying to view....so I wonder if there's an issue either with the SSD or with the preview cache itself. You could try renaming the preview cache, which would then force Lightroom to create a new (initially empty) cache.....then repeat the test, i.e. select a bunch of images, build 1:1 previews, then scroll through them in Loupe mode to see if there's a difference.



Will try, but still… with an SSD that read/writes [with substantial data on it already] at 900Mb/sec+, there really shouldn't be any delay if all it is doing is reading caches — which we know it isn't because the computer is generating the rendered images instead of using its 'previously cached' triplet of caches. It's obvious that there are two different processes going on with 'Loupe' / 'E' view and 'Develop' / 'D' mode. Definitely feels like a mysterious black box here.


----------



## tspear (Jun 24, 2015)

Skrat,

Do you have auto write XMP data enabled?
When I have this enabled and make changes in QuickDevelop the system is a lot slower to switch images. If I do not make changes, it does flip between images faster.

Tim


----------

