Victoria Bampton wrote:

 

Have you rendered 1:1 previews in advance?  If not, select all the photos in Grid view and go to Library menu > Previews > Render 1:1 Previews and wait for it to finish. 

I sem to recall hearing the OP's comment at some time in the recent past

Allow me to ask you one of my favorite questions:  After you render your 1:1 previews how many cores are active when you zoom to 1:1 view in the Library.  I will boldly predict that only 1 core is active at any given time while zooming.

Ian Lyons wrote:

 

Since the photo has already been rendered Lr only needs to load it. Why would this require more than one core?

That's an easy one to answer:  Beause zooming to 1:1 takes much too long.  That is, a number of seconds.  The image should "snap" to 1:1 within a second.  Take a look, for example, at Corel AfterShot (formerly Bibble Pro).

Ian Lyons wrote:

 

Bob_Peters wrote:

 

That's an easy one to answer:  Beause zooming to 1:1 takes much too long.  That is, a number of seconds.  The image should "snap" to 1:1 within a second.  Take a look, for example, at Corel AfterShot (formerly Bibble Pro).

 

 

Hmm, it takes around a second to zoom on 3 Mac systems I have here. That being said, the behaviour (i.e. animated zoom) is as per design (i.e  another BS feature that have Adobe loaded Lr with for years, all with the purpose of enhancing the user experience <cough>). You want to check compare how fast ACR displays spot heals compared to Lr (yep, more animation).

I only have access to 2 Mac systems at the present time, both running OS X (10.7.4)

MacPro 1,1 (creaky old):  around 4 seconds to zoom to 1:1 in the library or go to the next image at 1:1.

MacBook Pro (retina display):  roughly the same amount of time for the same operations noted above.

On the other hand the MacBook Pro computes the 1:1 previews in half the time required by the MacPro.  And zooming to 1:1 in the Develop module is much faster than zooming in the Library module on both computers.

I made the same observations on a "new" 2012, 3.33GHz, 6-core MacPro before returning it to Apple.  Too little bang for the buck!

The reason the time to traverse a few images at 1:1 is important is because I am fine-tuning the auto-focus of several lenses on a Nikon D800.  Having to wait several seconds to go from one image to the next is a pain in the rear.  I finally had to resort to loading 1:1 JPEG files into CS5 and checking the focus shift there.

I am more and more convinced that Lightroom is not as fast as it should be.  No, I have no idea why since I'm on the outside looking in and my training is in a field far removed from software.

There are faster raw processors on the market (I already mentioned one.) but I do not want to ditch Lightroom.

It's not inherently faster to work from a preview computed by the camera and embedded in the raw, than a preview computed by Lr and stored separately on disk.

1:1 zoom takes *way* less than a second for me (e.g. D300). And stepping from image to image is nearly instantaneous (image display-wise. histogram, metadata, and info display lag a bit). That's *if* the requisite view is available. Granted it would take longer to zoom 1:1 if camera is D800, but multiple seconds means something not right.

I think it's worth keeping in mind that some people are experiencing abnormally bad performance.

R

Bob_Peters wrote:

 

The stuff inlrdata does not look at all like a jpeg.

lrprev files are 1-7 jpegs (image data - no metadata) end-to-end with some garnish.

Download preview-exporter source code if you want to understand in greater detail.

R

The original post was made almost 9 hours ago and he has not commented on the several reply to his post. I am a bit perplexed since to OP did not indicate whether he in working in the Library Module or the Develop Module. If he is working in the Develop Module then building 1:1 previews will not help.

Rendering 1:1 previews may help a little, since it creates the ACR cache info, but my experience has also been that it helps *very* little.

That said, the first time one goes to 1:1 in Develop module it will always take multiple seconds. That's a design trait: rendering takes seconds and occurs on demand.

After the first time, it should be much quicker, since the info is subsequently cached efficiently in ram. At this stage, the operation is cpu bound, and should use all cores.

R

One core is all that can possibly be used (advantageously) to load the image from disk, unless newest SSD's are multiported and I'm not up-to-date about it (?). If one core doesn't have enough oomph to simultaneously decompress it while loading, then other cores could participate advantageously. What else Lr is doing and why things can take so long is beyond me.

Rob Cole wrote:

 

 

PS - Lightroom does use all cores (or should anyway) when zooming to 1:1 when image is already loaded because operation is once again CPU bound.

 

R

No, Rob.  On the 4 Macs I had access to Lightoom never used more than a single core at one time whem szooming an existing 1:1 preview to 1:1 in the Library module.  As I already said in post #6 I now have access to just 2 Mac systems:  a MacPro 1,1 (old!) and a new MacBook Pro "retina" (4-core i7).

Isn’t there a “database” associated with previews so part of LR’s slowness could be it figuring out exactly where the preview data is and comparing it with the last time the image was modified, more than loading the preview data once it knows?  Another variable might be how much of the LR and LR-preview database is currently cached in memory vs needing to be loaded from the disk/SSD.  The number of previews in the LR database would have an effect on this, and I remember people having issues using a converted previews database where things dramatically sped up when the older LR3 preview/preview-database (the entire previews-related folder) was deleted and LR4 rebuilt it, almost as if the structure of the database was different in LR4 but LR4 could use the LR3 preview data in some slower compatibility mode, though perhaps it is just the size of the database being small when LR first starts to build it from scratch.  Finally, I would imagine that having auto-XMP writing turned on is distracting for LR in terms of speed and resource usage that can also affect speed.

I would think that to avoid corruption in a single-user environment which LR is, database accesses are single threaded so if the auto-XMP writing is working on an image and especially if actually updating something, perhaps the previews database or regular LR database operation is queued behind it and delayed w/o any obvious reason.   And a background operation that reads through the database and many files to see if they’re up-to-date or not, would tend to flush other useful data from the disk-cache prematurely, causing LR to re-read information from disk that it wouldn’t if nothing else was going on.

Bob_Peters wrote:

 

I am loading the preview images from a 512GB SSD.  Do you really think that takes a significant amount of time?  This SSD has been clocked by Lloyd Chambers (http://macperformanceguide.com/mbpRetina2012-speed-ssd.html) at more that 400 MB/sec read speed.  Based on that measurement, reading a 25MB, D800 JPEG generated by Lightroom would take about 0.06 seconds.  How is the remainder of the time being utilized?

 

I am using a quad-core i7 with hyper-threading so there is absolutely no reason why those cores should not participate in the display of the image.  Again, just as an illustration, Corel AfterShot Pro uses all cores when zooming a preview to 1:1.  Photoshop CS5 uses all cores when zooming from 12.5% to 100%.  After that point the image has been chached (I assume) because zooming operationsdon't generate such obvious cpu-core activity.

 

Why shouldn't/can't Lightroom perform just as fast?

On my fast PC (six cores, SandyBridgeE) moving from one D800 nef to another in Library is instantaneous at 1:1, providing I have built the 1:1 previews previously. No lag whatsoever, no 'loading', the screen view just changes immediately I press the arrow button to move to the next image. So it is not that LR 'can't' do it, it does on my machine. Now you are using a Mac, so that is one variable, and the Mac version of LR is the other variable.

Bob Frost

bob frost wrote:

 

Bob_Peters wrote:

 

I am loading the preview images from a 512GB SSD.  Do you really think that takes a significant amount of time?  This SSD has been clocked by Lloyd Chambers (http://macperformanceguide.com/mbpRetina2012-speed-ssd.html) at more that 400 MB/sec read speed.  Based on that measurement, reading a 25MB, D800 JPEG generated by Lightroom would take about 0.06 seconds.  How is the remainder of the time being utilized?

 

I am using a quad-core i7 with hyper-threading so there is absolutely no reason why those cores should not participate in the display of the image.  Again, just as an illustration, Corel AfterShot Pro uses all cores when zooming a preview to 1:1.  Photoshop CS5 uses all cores when zooming from 12.5% to 100%.  After that point the image has been chached (I assume) because zooming operationsdon't generate such obvious cpu-core activity.

 

Why shouldn't/can't Lightroom perform just as fast?

 

 

On my fast PC (six cores, SandyBridgeE) moving from one D800 nef to another in Library is instantaneous at 1:1, providing I have built the 1:1 previews previously. No lag whatsoever, no 'loading', the screen view just changes immediately I press the arrow button to move to the next image. So it is not that LR 'can't' do it, it does on my machine. Now you are using a Mac, so that is one variable, and the Mac version of LR is the other variable.

 

Bob Frost

Wow! That's impressive.  I wish I had that much "horsepower"!

Rob Cole wrote:

 

Wow! That's impressive.  I wish I had that much "horsepower"!

 

Even if you don't, the lag should be a fraction of a second, not multiple seconds. If the latter, then you're being bitten by a bug.

 

Put previews on fast drive to minimize delay. It's the drive more than the CPU that limits speed in library sequencing, the opposite is true in Develop mode (assuming normal functioning).

Rob:

Please go back a few posts and read what I wrote:  I'm using a very fast, 512 GB SSD.

Rob Cole wrote:

 

One core is all that can possibly be used (advantageously) to load the image from disk (...)

Not necessarily. Preview images are compressed (JPEG if I remember correctly), and they must be decompressed to be displayed. Furthermore, when browsing back and forth, preview files will be in the file system cache of the OS, so the file loading can become effectively CPU-bound and consequently very fast compared to the decompression. Because JPEG decompression can be nicely parallelized, preview loading *can* benefit from multiple cores - depending on how fast the file reading is compared to the decompression (which depends on the preview dimensions). I can imagine that this may be even the case for loading from a fast disk (not cached) and large (>20MP) 1:1 previews.

And it seems that LR already uses multiple threads when loading previews: Render some 1:1 previews for large images, and then browse in loupe mode in 1:1 view (ok, that does not make real sense)... you will see that more than 1 core is used in sum.

*However*: When browsing in "fit" mode, LR uses the standard previews which decompress much faster, so parallelization will probably hardly make any difference. Note: Standard preview size must be set so the previews are large enough for the monitor, or else LR will fall back to 1:1 previews which will be slower, even if rendered in advance.