Experiencing performance related issues in Lightroom 3.x

[laurencec]

Hi

I just upgraded from lightroom 2.7 to lightroom 3. I then proceeded to import my old catalog. this all went fine but lightroom is so slow, the thumbnail previews take forever to load if I manage to have the patience to wait  for them.

is there a quick solution?? How can it be sped up?

thanks

Laurence

Message title was edited by: Brett N

[imajez]

Mikkasa wrote:

JayS In CT wrote:

Second the 10.6.4 causing some sluggishness.

Who knows if this is relevant & useful or pointless thread cruft, but I've deliberately avoided 10.6.4 due to reported bugs. My 10.6.3 system is a rock and LR3 runs well enough for me. Is there an acronym for If It Ain't F@¢ked Don't Fix It?

I stupidly upgraded to 10.6.4 without doing my usual wait and see what new bugs there are.

I have now rolled back to 10.6.3 and reinstalled all basic applications like Opera, Chrome, Chronosync, Carbon Copy Cloner, iShowU, SnapzProX, Toast Titanium, PathFinder, CS5 Master collection + LR.  LR now seems to run just dandy even with both monitors being used full screen [1900 x1200px],  just like on my Laptop also full screen 1920x1200 and running 10.6.3.

I now have better [normal] performance from a catalogue and images on a 2.5" 5200rpm ext USB drive than from internal 3.5" 7200rpm data drives when running 10.6.4.

I shall monitor LR's performance as I add any plugins to LR, music software or alternative image software like Phocus to see if anything makes it slug like again.

[DanTull]

LR now seems to run just dandy even with both monitors being used full screen

Interesting. I'd heard (mostly in the gaming community) that 10.6.4 was problematic . Thanks for reporting back on this finding!

DT

[Butch_M]

Dan .. from what I have read at various sources .... the 10.6.4 updates seems to be as hit and miss for problems as LR3.0 has been ... no problems for some, irritating annoyance for others ... I've held off on the update until the dust settles to make sure ...

[JayS_In_CT]

DanTull wrote:

LR now seems to run just dandy even with both monitors being used full screen

Interesting. I'd heard (mostly in the gaming community) that 10.6.4 was problematic . Thanks for reporting back on this finding!

DT

Dan,

I can't imagine the team was unaware of the OS issues, at least I hope not.  There is a also a report of 10.6.3 and 10.6.4 causing CPU overheating on Mac Pro's with onboard audio.  Also, we can't look to pin this on the OS given both Windows and Mac users seem to be having similar issues regarding Screen rez, CPU, 64 vs. 32 bit, etc.  As I stated above, I was on the beta when I had 10.6.4 and noted a change, but at the same time, my LR 2.7 ran as it always did.  So maybe the clue is somewhere in there.  Whatever caused a performance impact in LR relative to 10.6.4 was there in the beta (caused me to roll back to 10.6.3.  More likely though, whatever that was, is contributing to the current issues with the production version.

Maybe its me though Dan, but how much of a handle does the team have on some of this?  You guys must have the hardware in house for testing.  Surely you can see some of the same issues we're all reporting here, at least at gross levels.  I know this is of little or no use, but right now, LR 3.0 feels and acts "bloated".  It isn't the tradeoffs you spoke about earlier, etc.  It just feels like this release isn't all tied together as good as it should have been (or could have been).  There are too many common stories coming out about load times, the issues of images not resolving, etc. to make these indivdual machine issues.

Folks with massive machines who are running fine are not as representative as folks whose machines ran 2.7 fine and expected the same level (if not better) performance on 3.0.  That isn't to say time doesn't require us to make hardware upgrades.  If I can render HD video on my MBP with less memory and with less CPU utilization than LR 3 needs to do an import or export, then there is an issue with LR 3 being a less than ideally optimized I'm thinking.  This is all very familiar to the stories we had here with 2.0 though.. so I realize some time is needed.  We do need some of the major issues hit soon though.

Jay S.

[asu_chic]

Again, agreed.  I have not upgraded to "snow kitty", nor have I made any system changes at all and am having the same issues on 10.5.8.  It is

not a "mac" issue and the Beta and Beta 2 "just worked".

asu_chic

[JayS_In_CT]

asu_chic wrote:

Again, agreed.  I have not upgraded to "snow kitty", nor have I made any system changes at all and am having the same issues on 10.5.8.  It is

not a "mac" issue and the Beta and Beta 2 "just worked".

asu_chic

asu_chic,

There were some good updates in the 10.6.x updates, and 10.6.3 seems fine.  You can still find the DMG files for the older releases (I have 10.6.3).  If you have a spare external USB drive that you can set up as a clone (making it bootable at startup), you can apply 10.6 and see if you hit any issues before laying it over your main OS drive.  They are completely separate..  Nothing you do on the external drive spills over to the main drive.  A good way to run a test bed before any major updates to a system.  Sorry if something you're already familiar with.

Jay S.

[asu_chic]

Thanks JayS.  I specifically bought my newest computer earlier this year with 10.5 on it.  The last  B&H had in stock as a matter of fact. I thus have the option of Snow Leopard, or not, until Adobe and Canon catch up with me.    I have an IMac G5 running Tiger for my printers, of which there are 5 Epsons, and two are oldies. The IMac is not an Intel system or I would not have upgraded at all.  Needed Intel for the new LR3B.  I have used Lightroom since it first came out with CS2, 3 and 4, but I am sitting on the sideline for CS5 until some bugs are worked out.  I could sure use some

of those new features!  I just want the final product to work like the Beta did on my system which has not been altered or upgraded in any way since day one of the Beta.  So far in limited trial, working in 32 bit mode seems to help a little, as noted by others, in that it takes longer to bog and clears more quickly. This is not an answer to the problems, however.

asu_chic

[DanTull]

I can't imagine the team was unaware of the OS issues, at least I hope not.

No, as I noted I'd heard of it, but had very few hard data points and wanted to thank the poster for providing one.

Also, we can't look to pin this on the OS...

Obviously. I've been gathering notes on the various posts from people who've "solved" their issue and there are clearly a bunch of factors at play.

Also, as I noted before, there are several bugs fixed internally. Some of them have sufficiently sweeping effects that it's hard for me to sort out which of the described issues would be fixed if we handed out the newest internal build today and which would not. The only way I can know that right now is to reproduce the conditions with 3.0 internally and then confirm that they go away with the internal latest version.

You guys must have the hardware in house for testing.  Surely you can see some of the same issues we're all reporting here...

Well, we're much fewer in number than even the number of participants in this thread (and only a small subset of those are looking at these issues specifically), much less the LR userbase as a whole. Some of the issues are ones I can see (as noted above, I think at least some of them are fixed internally). Others (including some of the severe ones) are still elusive.

Example: I'd love to confirm the bug where the Windows 64-bit app consumes all the memory and totally falls down. So far, I can't make it happen. I've replicated all the details I can find and (like some others chiming in on the thread) can barely get it to clear 1.5GB on my system. I have more things to try, but the experiments take time.

As noted before, I do know that on modest hardware, the new image process version's additional CPU demands may push the system over the tipping point where it will not be usable compared to 2.7 -- those reports don't surprise me. I wish that were not the case, but there we are. I'm more keen on finding and pinning the cases where the app falls over hard and then see where we are after the field is cleared a bit.

DT

[JayS_In_CT]

DanTull wrote:

As noted before, I do know that on modest hardware, the new image process version's additional CPU demands may push the system over the tipping point where it will not be usable compared to 2.7 -- those reports don't surprise me. I wish that were not the case, but there we are. I'm more keen on finding and pinning the cases where the app falls over hard and then see where we are after the field is cleared a bit.

DT

Dan,

Good update as a whole and thanks.  On the above though, I don't remember anything in the new LR literature that talked to putting Core 2 Duo's into a tailspin..  Again, Adobe made the claims of improved performance.. Nothing there stated new CPU requirements as such.  Again, it surprises many of us who, on those "modest" systems didn't experience this on the beta.  I'll settle for the same performance as I had in 2.7, and I think that should be doable by Adobe.  I hope (and I think many would echo) that after the fact, Adobe isn't going to say ...  "Well, now that we built it, we kinda went over the top in some areas so yeah it won't work like we thought".  O.K., perhaps not quite the way it would come out.  As I said, some compromises are expected.. Maybe I won't have a bunch of other things running when doing LR.. I can probably adjust to that.  I don't know that "there we are" is the type of answer we're all waiting to hear.  Again, may be early cause we don't know the impact on the overall workflow of some of the other issues, but please convey, at least from me, that saying the process model came out more CPU bound than we thought, "so there we are" isn't really what folks are looking for.  Sounds a bit defeatist at this point like there's nothing left to do in that new process module to trim it down or optimize it.

Jay S.

[Guest]

JayS In CT wrote:

DanTull wrote:

As noted before, I do know that on modest hardware, the new image process version's additional CPU demands may push the system over the tipping point where it will not be usable compared to 2.7 -- those reports don't surprise me. I wish that were not the case, but there we are. I'm more keen on finding and pinning the cases where the app falls over hard and then see where we are after the field is cleared a bit.

DT

Dan,

Good update as a whole and thanks.  On the above though, I don't remember anything in the new LR literature that talked to putting Core 2 Duo's into a tailspin..  Again, Adobe made the claims of improved performance.. Nothing there stated new CPU requirements as such.  Again, it surprises many of us who, on those "modest" systems didn't experience this on the beta.  I'll settle for the same performance as I had in 2.7, and I think that should be doable by Adobe.  I hope (and I think many would echo) that after the fact, Adobe isn't going to say ...  "Well, now that we built it, we kinda went over the top in some areas so yeah it won't work like we thought".  O.K., perhaps not quite the way it would come out.  As I said, some compromises are expected.. Maybe I won't have a bunch of other things running when doing LR.. I can probably adjust to that.  I don't know that "there we are" is the type of answer we're all waiting to hear.  Again, may be early cause we don't know the impact on the overall workflow of some of the other issues, but please convey, at least from me, that saying the process model came out more CPU bound than we thought, "so there we are" isn't really what folks are looking for.  Sounds a bit defeatist at this point like there's nothing left to do in that new process module to trim it down or optimize it.

Jay S.

    It should be noted that identifying the problem is the very first step to fixing it.     I have been saying for several days exactly the same thing - that is that the 3.0 CPU requirements might put 3.0 past the knee of the curve of CPU capabilities on CPU cycle challenged systems. Everything else we discuss here is designed to get a balanced system and thus expose the CPU as the limiting factor.

   We should take it as good news that maybe Dan has found something rather than assume that his "turn of phrase" implies anything more.  If in fact, they realize that this is a CPU bound problem, the next step is to create a controled and repeatable experiment that demonstrates the problem, and then measure where CPU gains can be accomplished without sacrificing function. 

   Again, if Dan is correct, we should take this as very good news. He is correct also that hard failures are severity 1 problems and should be pursued first.

[asu_chic]

Well stated by all of you gentlemen and let's hope this is progress.  All else aside, it is rather disturbing to those of us on a wide array of systems that used the Beta and made our choice to upgrade based on that usage and experience.  I for one said "oh yes" on day one.   When Beta 2 came out and we could actually use the fully functioning NR it was heavenly.  Unfortunately, Beta is for testing and feed back, and changes that are made subsequent to a beta release don't get "beta tested" by the end users for feedback.  Even though this is true for all software development, it has left us feeling a little "blindsided" if you will, especially considering how the beta we used worked.  Even though we know we will never actually see all the bells and whistles before a release, it is never anticipated that a finished product will be less than a beta product or that our systems that worked with the beta will not be "adequate" for the end product.  On the contrary, the speculation is always about what "goodies" we are going to be pleasantly surprised with.  At at minimum, we would expect to be advised at the time of release of minimum system requirements.  The issue may well be that the project teams were using systems configured such as to not present an issue and the "user testers" were not in on the last changes so there was no way of actually knowing at what point a "wall" was hit.  Hopefully we will be seeing some updates shortly.  Thank you to Dan for keeping us informed and for all his help!

asu_chic

[imajez]

asu_chic wrote:

When Beta 2 came out and we could actually use the fully functioning NR it was heavenly.  Unfortunately, Beta is for testing and feed back, and changes that are made subsequent to a beta release don't get "beta tested" by the end users for feedback. 

There was a public beta programme which had two releases, yet alongside that there is a pre-release programme with many end users taking part and offering feedback in the pre-release forums up until and even after final GM release.

When you are doing beta testing, you may get new builds once a month or every few days.

[asu_chic]

imajez, I was invited to be a beta tester however, could not do so as I did not have an intel unit until the public beta came out. As a public beta tester I was quite pleased with the beta and beta 2 releases and thus did not anticipate what is occurring now.  I suspect the Adobe developers and those who

participated in the testing likely were, as previously stated, "using systems configured such as to not present an issue ". This is admittedly, purely speculation on my part. I am a photographer, not a programmer! 

[JayS_In_CT]

sherlocc wrote:

JayS In CT wrote:

DanTull wrote:

As noted before, I do know that on modest hardware, the new image process version's additional CPU demands may push the system over the tipping point where it will not be usable compared to 2.7 -- those reports don't surprise me. I wish that were not the case, but there we are. I'm more keen on finding and pinning the cases where the app falls over hard and then see where we are after the field is cleared a bit.

DT

Dan,

Good update as a whole and thanks.  On the above though, I don't remember anything in the new LR literature that talked to putting Core 2 Duo's into a tailspin..  Again, Adobe made the claims of improved performance.. Nothing there stated new CPU requirements as such.  Again, it surprises many of us who, on those "modest" systems didn't experience this on the beta.  I'll settle for the same performance as I had in 2.7, and I think that should be doable by Adobe.  I hope (and I think many would echo) that after the fact, Adobe isn't going to say ...  "Well, now that we built it, we kinda went over the top in some areas so yeah it won't work like we thought".  O.K., perhaps not quite the way it would come out.  As I said, some compromises are expected.. Maybe I won't have a bunch of other things running when doing LR.. I can probably adjust to that.  I don't know that "there we are" is the type of answer we're all waiting to hear.  Again, may be early cause we don't know the impact on the overall workflow of some of the other issues, but please convey, at least from me, that saying the process model came out more CPU bound than we thought, "so there we are" isn't really what folks are looking for.  Sounds a bit defeatist at this point like there's nothing left to do in that new process module to trim it down or optimize it.

Jay S.

    It should be noted that identifying the problem is the very first step to fixing it.     I have been saying for several days exactly the same thing - that is that the 3.0 CPU requirements might put 3.0 past the knee of the curve of CPU capabilities on CPU cycle challenged systems. Everything else we discuss here is designed to get a balanced system and thus expose the CPU as the limiting factor.

   We should take it as good news that maybe Dan has found something rather than assume that his "turn of phrase" implies anything more.  If in fact, they realize that this is a CPU bound problem, the next step is to create a controled and repeatable experiment that demonstrates the problem, and then measure where CPU gains can be accomplished without sacrificing function. 

   Again, if Dan is correct, we should take this as very good news. He is correct also that hard failures are severity 1 problems and should be pursued first.

Sherlocc,

I know how hard you've been working through the CPU angle, and clearly we know there are some issues there.  I think I tried to give Dan the benefit of the doubt but the whole phrase did sound more like " have to accept it as is" vs. "hmm, this might be an area for us to look at".  Again, the overall impact of the new Process module may or may not put things over the top depending on what "fixes" come along with the updates.  Perhaps other areas may release enough system resources back to allow the Process module to be more efficient.  That said, the new Process module itself can't and shouldn't hold the CPU somewhat hostage.  As I said, when I can sit there and render HD video and not have the impact I have with LR 3.0 doing what I consider to be at least as significant an I/O function, exporting, then I think there is clearly something wrong, in general, in how LR 3.0 is balancing all of its needs.  I also agreed and said, fix the big issues first and fine tune later.  My only "issue" was that it sounded like the process module is what it is and therefore that was it.

"As noted before, I do know that on modest hardware, the new image process version's additional CPU demands may push the system over the tipping point where it will not be usable compared to 2.7 -- those reports don't surprise me. I wish that were not the case, but there we are."

"not useable" compared to 2.7 is a pretty big leap I think you'd have to agree.  That's not, a bit slower than 2.7 or may not multitask like 2.7..  "not useable" just raised a whole different image in my mind.

Jay S.

[DanTull]

Let me clarify what "I wish that were not the case, but there we are." or my lack of surprise. The image processing improvements valued quality over precise system requirement parity. I can't speak to how much room is in there for optimization, but I can say that it was an accepted tradeoff that it would take more CPU in trade for enabling the noise reduction features in the 2010 process version.

Now, there are bugs on this thread (the "tailspin" variety) that are well outside of that expectation. But reduced interactive framerates when making Develop adjustments? As it stands, that's not something we're looking at changing for a dot release as far as I know.

Also, when I say modest hardware, I'm taking about my single core P4 (3.6 Ghz, IIRC) box running XP or my Core Duo (no 2, 32-bit only, a generation earlier) iMac each with 2 GB of RAM. For large photos from newer (or just higher end) cameras, it can sting more than a bit to do some kinds of adjustments. Now, in LR2 those same images would cause those machines to strain, too, and it also made the UI hitch pretty hard. In LR3, it takes a bit longer for the UI to catch up at times, but the movements aren't so jerky.

I don't recall ever seeing any claims of faster "image processing" performance. A lot of the performance work was re-architecture of some of the mechanisms to improve UI responsiveness even in large catalogs. That's a totally separate set of benchmarks and measurements. The fact that it didn't specify is unfortunate as it probably set expectations improperly.

That said, I'm still going to be looking at baselines I have from the Beta2 build and the final build for discrepancies and try to figure out what's going on there. Needing more CPU oomph than 2.7 is expected. Needing more than Beta2 when lens corrections are not in the mix is more disturbing to me.

DT

[JayS_In_CT]

DanTull wrote:

Let me clarify what "I wish that were not the case, but there we are." or my lack of surprise. The image processing improvements valued quality over precise system requirement parity. I can't speak to how much room is in there for optimization, but I can say that it was an accepted tradeoff that it would take more CPU in trade for enabling the noise reduction features in the 2010 process version.

Now, there are bugs on this thread (the "tailspin" variety) that are well outside of that expectation. But reduced interactive framerates when making Develop adjustments? As it stands, that's not something we're looking at changing for a dot release as far as I know.

Also, when I say modest hardware, I'm taking about my single core P4 (3.6 Ghz, IIRC) box running XP or my Core Duo (no 2, 32-bit only, a generation earlier) iMac each with 2 GB of RAM. For large photos from newer (or just higher end) cameras, it can sting more than a bit to do some kinds of adjustments. Now, in LR2 those same images would cause those machines to strain, too, and it also made the UI hitch pretty hard. In LR3, it takes a bit longer for the UI to catch up at times, but the movements aren't so jerky.

I don't recall ever seeing any claims of faster "image processing" performance. A lot of the performance work was re-architecture of some of the mechanisms to improve UI responsiveness even in large catalogs. That's a totally separate set of benchmarks and measurements. The fact that it didn't specify is unfortunate as it probably set expectations improperly.

That said, I'm still going to be looking at baselines I have from the Beta2 build and the final build for discrepancies and try to figure out what's going on there. Needing more CPU oomph than 2.7 is expected. Needing more than Beta2 when lens corrections are not in the mix is more disturbing to me.

DT

Dan,

Let me try to be more clear.  I have zero hitches with 7D images in 2.7.. nothing nada zip.  You may have hidden it better but you talk about jerky movements being improved in LR 3.  I won't speak for everyone, but I think you've heard many times 2.7 was fine.  My UI had no hitches, my load times were relatively fast, etc.  all with the same type of 7D images that LR 3 is straining on, not 2.7.  Why is it taking double the time in LR 3 in Library to render or load an image that for all intents and purposes is the same as one in 2.7.  I'm don't think the 2010 process and noise reduction is at play there.  How is it that when in Develop and with 2003 set, it is taking almost twice as long to render and load?  My point being that while the 2010 Process adds a load, there are other things that are slowing the workflow down substantially.  If LR from one release to another is going to near double its CPU requirements to do much all the same work, I don't know what it will take when LR 4 comes around.

Also, I didn't suggest that the 2010 Process or Develop mode be "throttled" back.  What I've been saying is that I guessing there are issues there as well to look at.  None of this is totally unexpected in my mind.  As I said, we've been here before with LR 2.0.  The difference is that you seem to be suggesting that there is absolutely nothing in the 2010 Process that warrants even being looked at to see if it is buggy in any way.  Maybe I'm reading your comments wrong, but you seem to have a constant theme about the CPU and 2010 Process of that's just the way it is, so accept it.

Sorry if this isn't the case.. but again folks here are saying they are going BACK to 2.7.. that must be telling you something.

Jay S.

[DanTull]

How is it that when in Develop and with 2003 set, it is taking almost twice as long to render and load?

Yeah, I'm not calling that expected.

I've seen some people referring less clearly to "LR 3 is slower than 2.7" and in the case when they're using the 2010 process version, that's going to be the case and it's expected. Different story.

DT

[JayS_In_CT]

DanTull wrote:

How is it that when in Develop and with 2003 set, it is taking almost twice as long to render and load?

Yeah, I'm not calling that expected.

I've seen some people referring less clearly to "LR 3 is slower than 2.7" and in the case when they're using the 2010 process version, that's going to be the case and it's expected. Different story.

DT

Dan,

Maybe and I say maybe because we don't yet know what that threshold is yet due to the other issues.  Yes, more CPU is required for 2010, I think we've all got that.    but the user experiences I think people are talking about here shouldn't be cubbie holed to the issue being 2010 Process and its added requirements, that is unless you're telling us the CPU requirement for LR 3 with 2010 process DID double.  I'm hoping not...  I mean we're not all able to keep up with Moore's law on a regular basis.  In your above statement, some of it may be 2010, but I'm betting a lot of it is all the other issues, and I guess that's all I was trying to say from the start.

Like your second note..  Have a good weekend.

Jay S.

[DanTull]

Good clarification. Yes, double is much more severe than I expect even for process version 2010 (with default/initial settings). I think it may diverge a bit more at the high end of the noise reduction scales and perhaps with some lens corrections, but even then I don't _think_ it's supposed to be nearly double.

Have a good weekend.

You too. Thanks for hanging in there.

DT

[areohbee]

DanTull wrote:

Some of them have sufficiently sweeping effects that it's hard for me to sort out which of the described issues would be fixed if we handed out the newest internal build today and which would not. The only way I can know that right now is to reproduce the conditions with 3.0 internally and then confirm that they go away with the internal latest version.

Why not pass out that internal build and let people tell you what it fixes and what it doesn't?

Rob

[imajez]

DanTull wrote:

LR now seems to run just dandy even with both monitors being used full screen

Interesting. I'd heard (mostly in the gaming community) that 10.6.4 was problematic . Thanks for reporting back on this finding!

DT

To clarify - That's working fine, now I'm not using 10.6.4.  I rolled back to 10.6.3 and LR3 is usable again

[JayS_In_CT]

imajez wrote:

DanTull wrote:

LR now seems to run just dandy even with both monitors being used full screen

Interesting. I'd heard (mostly in the gaming community) that 10.6.4 was problematic . Thanks for reporting back on this finding!

DT

To clarify - That's working fine, now I'm not using 10.6.4.  I rolled back to 10.6.3 and LR3 is usable again

imajez,

So, is it "dandy" or "useable" ?  🙂  Are you getting any more of the symptoms?  I rolled back to 10.6.3 during the beta as I said, then installed LR 3.0 over that a week or so later.  Again though, no issues with LR 2.7 and 10.6.4 so not sure what changed in LR 3.0 that may be conflicting with later OS X releases.

Jay S.

[imajez]

JayS In CT wrote:

imajez wrote:

DanTull wrote:

LR now seems to run just dandy even with both monitors being used full screen

Interesting. I'd heard (mostly in the gaming community) that 10.6.4 was problematic . Thanks for reporting back on this finding!

DT

To clarify - That's working fine, now I'm not using 10.6.4.  I rolled back to 10.6.3 and LR3 is usable again

imajez,

So, is it "dandy" or "useable" ?  🙂  Are you getting any more of the symptoms?  I rolled back to 10.6.3 during the beta as I said, then installed LR 3.0 over that a week or so later.  Again though, no issues with LR 2.7 and 10.6.4 so not sure what changed in LR 3.0 that may be conflicting with later OS X releases.

Dandy/usable/fine all same thing as they =  🙂

LR3 now I've reverted back to 10.6.3, has no lag on brushes, which seemed to be a big issue with many people and the zoom to 100% and tedious loading forever along with blank thumbnails in grid are no longer present.

Not had opportunity to fully test system out, hopefully will have time tomorrow.

[JayS_In_CT]

imajez wrote:

Dandy/usable/fine all same thing as they =  🙂

LR3 now I've reverted back to 10.6.3, has no lag on brushes, which seemed to be a big issue with many people and the zoom to 100% and tedious loading forever along with blank thumbnails in grid are no longer present.

Not had opportunity to fully test system out, hopefully will have time tomorrow.

Imajez,

It does sound like you're more than just useable, and are "dandy".    Glad to hear.  Let us know how you continue to fare.  I may want to compare notes.  I never had those blank thumbnails, but my loads for the same 7D like images are slower on LR 3 vs. 2.7.. not impossible, but at times double what I see in 2.7.

Jay S.

[JayS_In_CT]

imajez wrote:

Mikkasa wrote:

JayS In CT wrote:

Second the 10.6.4 causing some sluggishness.

Who knows if this is relevant & useful or pointless thread cruft, but I've deliberately avoided 10.6.4 due to reported bugs. My 10.6.3 system is a rock and LR3 runs well enough for me. Is there an acronym for If It Ain't F@¢ked Don't Fix It?

I stupidly upgraded to 10.6.4 without doing my usual wait and see what new bugs there are.

I have now rolled back to 10.6.3 and reinstalled all basic applications like Opera, Chrome, Chronosync, Carbon Copy Cloner, iShowU, SnapzProX, Toast Titanium, PathFinder, CS5 Master collection + LR.  LR now seems to run just dandy even with both monitors being used full screen [1900 x1200px],  just like on my Laptop also full screen 1920x1200 and running 10.6.3.

I now have better [normal] performance from a catalogue and images on a 2.5" 5200rpm ext USB drive than from internal 3.5" 7200rpm data drives when running 10.6.4.

I shall monitor LR's performance as I add any plugins to LR, music software or alternative image software like Phocus to see if anything makes it slug like again.

Good, I won't say that's the silver bullet though since there are Mac users on 10.5.x and Windows users with issues still.    I rolled back to 10.6.3 and while LR 3 was better than on 10.6.4, I'm can't declare victory yet.. but it is an indication of the relationship between the app and the OS.  None of the other apps, including LR 2.7 seemed impacted by 10.6.4 when I had it on my system, and in my case, I still had the beta when I had 10.6.4 on my MBP..  That would indicate something as far back as the second beta was different as it may relate to the OS.  To me though, I keep "no thank you" when I get the 10.6.4 reminder.

Jay S.