LR very unresponsive and slow

[IvanJekic]

Hello,

This is the main issue that concerns me, because LR was made to 'take it easy' - but usually working in LR is a PAIN. :shock:
I was using 1.3.1 - now 1.4.1 and 2.' beta. In my experience, all of them are slow, while 2.' is slightly slower.

My catalogs usually have about +15' photographs or more. I regularly optimize them, I set preview quality to 1'24/low. That improved the speed a bit, but when going on 1:1 I still have to wait about 3'sec to actually see the full image.

What's worse though is that the commands in DEV panel have a great lag. Sliders, knobs, buttons... work like a thunderstorm. First you see the lighting (press a button) then, after a few secs you hear the sound (see what you have done to the image).

My machine isn't bad at all: Celeron 2.91ghz, 2gb ram, optimized WinXP, SATA2 hard disks, Radeon X3''. Photoshop CS3 is fast and ACR is MUCH faster in CS3 than in LR!

Unfortunately there's no Performance tab in LR to change the use of RAM. Looking at the task manager, LR is using/allocating just a tiny bit of ram.

My question is: what can I do to actually make LR usable?
Thanks!!

 

[Ian Farlow]

My first guess is that the Celeron CPU is not up to par for this type of software. Lightroom doesn't rely on a GPU like Aperture does, and so it requires a high-performance CPU, and the Celeron, in my opinion, just isn't powerful enough.

 

[IvanJekic]

Well, I guess you're right about Celeron, but how come the CS3/ACR isn't slow at all? At least, it allows me to work fast and without waiting (even with many images opened in the same time). That's more than enough for me.
That's strange, because PS is much more powerful (in terms of usage) than LR.

But if Celeron is really responsible for this, I'll have to buy another proc...

 

[Brad Snyder]

Ivan,

I believe that Ian is correct.

LR's shrink-wrap retail package System Requirements:

Minimum Intel(R) Pentium 4 processor.

The LR2 beta release has not been optimized/tuned for performance at this point, so don't have high expectations there.

As for improving what you have, most LR performance issues reported come from disk i/o bottlenecks. Keep your catalog files/previews (i.e., *.lrcat *.lrdb) on your fastest drive. If possible keep the source image files on a separate fast drive.

LR has problems with memory fragmentation in Windows, due principally to using OS subsystems to manage memory. If I'm not mistaken, and remember correctly, PS has its own internal memory management system, bypassing the Windows services. That's why you can adjust memory usage in the one and not the other. Obviously, the engineers are acutely aware of the problems and I assume it's a matter of when (rather than if) they can resolve the issues.

 

[Mark Sirota]

Your preview size may be too small -- it should be at least as wide as your monitor, or wider if you often work in "Fill" view.

That said, it sounds like it's just taking a long time to build 1:1 previews. This is largely a function of CPU power and disk I/O.

 

[Ian Farlow]

Well, I guess you're right about Celeron, but how come the CS3/ACR isn't slow at all? At least, it allows me to work fast and without waiting (even with many images opened in the same time). That's more than enough for me.
That's strange, because PS is much more powerful (in terms of usage) than LR.

But if Celeron is really responsible for this, I'll have to buy another proc...

There might be a number of reasons that PS/ACR/Bridge work better with the Celeron, but because Lightroom is a new and completely different bit of software, it likely has more stringent requirements for processing power than Photoshop. There may be optimization issues with Lightroom as well, but I'm not sure about that. Remember that Lightroom handles file management very differently than Bridge and Photoshop/ACR do.

I would suggest looking for another CPU, and would expect that the performance increase in both Lightroom and Photoshop will be an eye opener for you.

As others have stated, you might want to rethink your preview rendering size, and might need to consider if there are significant disk bottlenecks to overcome.

 

[IvanJekic]

Thanks everyone! I'll try to investigate. At least I know where the problem is.