Improving browsing performance in Library mode

  • Thread starter Thread starter Bosco Cheung
  • Start date Start date
Status
Not open for further replies.
B

Bosco Cheung

Guest
Dear all,

My experience in Library mode has been very satisfactory (cataloging, keywording, making collections, etc) except for the speed of browsing.

In library mode my screen displays a grid of 5 (rows) x 8 (cols) of thumbnails. Whenever I page down I can see LR (a) firstly display a very rough quick version, and then (b) updated with a blurred version and (c) finally a readable thumbnail. The whole 3-phase display/refreshing process takes 5-1' secs.

Catalog info:
- 6'''+ photos, all raw files from my Canon 4''D
- Browsing a collection of around 4''+ photos
- ALL photos have generated standard preview at import (and most of them have certain amount of edits in develop mode)
- Have generated two sets of standard previews in (i) 2'48 pixels + medium quality and (ii) 1'24 pixels + medium --> no major improvement in browsing experience.
- Deliberately make a collection where there is no metadata or develop settings --> same (slow) speed


Whilst it is obvious that a faster CPU with more RAM and a faster HDD will bring overall improvement, my question is --> which particular hardware is more important from the point of view of Library mode thumbnail browsing?

My logic (could be wrong!) is: in Library mode when I jump around browsing the thumbnails, LR is working on majorly 2 things (a) reading the .ircat file for the sorting, metadata, and other parametric information and (b) reading the small preview files for displaying the thumbnails (saved in the large but well-organised directory structure of '-9,A-F, etc etc.)

Therefore, for browsing in Library mode, a faster HDD/ storage array will boost performance more than a faster CPU -- (an extreme example could be: upgrading to an array of four 15K-rpm drives in Raid-' will help more than upgrading CPU from 3GHz to 4GHz). I also noticed from Windows memory management that LR generally uses around 1GB of RAM in Library mode, out of my 2GB installed -- I therefore would suggest that adding more RAM may not speed up as much as the case of upgrading HDD.

Am I mistaken or missing anything? Thanks in advance for any kind instructions/thoughts/sharing.

Regards
Bosco
 
I believe the scenario you outline is correct.

Disk, memory, CPU in that order

In my experience, higher disk throughput, better LR performance. Personally, I try to keep the catalog and source photo files on separate internal drives on the theory "the more read/write heads, the better". I speculate that the ideal would be to further segregate the preview cache to a 3rd internal drive, but I haven't tried that.

More memory helps up to 2GB on Windows. Additional memory is possibly useful, but problematic. Search threads for "/3GB switch". [The short story is that memory fragmentation, not absolute size is the limiting factor on Windows][No experience with 64bit versions]

Any modern CPU is probably fast enough.
 
Thanks Brad.

Will try to split up the raw data drive and the catalog drive as you suggested. (however, not too sure if we can choose where to save the previews as I guess the previews must be saved next to the .ircat file?)

Bosco
 
Yes, the previews are usually automatically stored next to the catalog file. I seem to remember that Sean manage to move them using Symbolic Links a while back (I'm sure it was on his blog), but I still haven't found time to try that yet.
 
Bosco Cheung;1'751 said:
Thanks Brad.

Will try to split up the raw data drive and the catalog drive as you suggested. (however, not too sure if we can choose where to save the previews as I guess the previews must be saved next to the .ircat file?)

Bosco

I haven't tried it either. Don't even know if it's possible(Although as VB says, perhaps you can do it on a Mac). Was just thinking out loud, not always the best idea, as experience keeps trying to teach me ....:D
 
May I take this chance to share some thoughts/feeling here:

In practice photographers may only deal with a few small collections at time whereby the whole catalog itself may comprise 1','''+ photos. My most common two scenarios are (i) keywording the latest 1 or 2 imports or (ii) filtering out 1''+ photos by keywords/metadata from a catalog (of say 1','''+ pics) and then further shortlisting one-by-one by hitting the "b" key. Scenario (i) demands quick jumping up and down in Library mode since I may want to Ctrl-click to select all the photos with, say, my friend John in it so that I can apply "John" as a keyword -- I just cant wait a few seconds each time I scroll down until I can see who is actually in the picture. Scenario (ii) is similar, manual picking, say, 5' pics out of a 2'' filtered set is no easy decision and naturally I need to scroll/page up and down heavily just to compare which ones should be chosen (and big thanks to the shortcut "b"!)

What I hope is seeing memory / scratch disk management options in the forthcoming LR 2.' (as in PS), so that the efficiency on a most active subset can be optimized. Thinking aloud here, the ability to cache the most-accessed metadata from .ircat on one scratch disk and a separate option to cache the most-accessed previews on another may help a lot.

Performance is key, and perhaps hardware innovation will catch up so quick that inefficiency today will become non-issue in the short future. (We can probably feel the speed of hardware development when comparing filter actions in PS on a new and old PC/Mac.) Slightly different from PS (CPU and RAM hungry) LR also requires speedy random access from an array of thousands preview files - it can be very random indeed, because of its sorting/filtering nature. Well, this is the crux of a cataloging software, and that's why I was suggesting in my first post that a server-type setup may help this quasi-multi-user-access pattern. Perhaps amateur photographers should also consider server-class storage system on top of speed and memory -- for swift cataloging and a more secure archive.

Should get back to my photos and LR now. Last but not least --> Great job LR Engineers! I like LR. I like its cataloging capability (Library), parametric editing engine from Camera Raw (Develop) and the simple but "plug-in-able" output modules (esp Web). As a version-1 product, there's already a lot to praise.


Bosco
 
I have same issue. WHy isn't it like Aperture?

I have just visited a friend with Aperture. His grid view was SOO much better than LR as the images all looked sharp when he scrolled around. If LR caches the preview why does it still take time for them to become sharp? Oh:!: and the iage umbers dissappear for a while too. Doesn't make sense to me.
John
 
Status
Not open for further replies.
Back
Top