Lightroom 3.3 Performance Feedback

Report · Dec 02, 2010

Please use this discussion topic for your feedback on Lightroom 3.3 RC and the final Lightroom 3.3 release when it becomes available. The Lightroom team has tried very hard to extract useful feedback from the following discussion topic but due to the length and amount of chatter we need to start a new, more focused thread. Please post specifics about your experience and be sure to include information about your hardware configuration.

Regards,

Tom Hogarty

Lightroom Product Manager

Report · Apr 09, 2011

@thewhitedog: Yes, you understood it correctly.

And, no, I'm not going to remove the internal card reader just for Lightroom. I built It into this system because it has 5 card slots, 3 USB ports, an eSata port, and a 5-vdc port. That would be silly, especially since all my other software has been working just fine with it from day one.

And you know, even LR3, once it gets past the long delay, and finally gets to the import screen, has no problem reading any of the media cards plugged into this reader. And after it finally imports, LR3 appears to be pretty snappy doing everthing else.

Hey, I really liike the direction that Lightroom is going with the new features, so hopefully I'll be able to find or figure out some other workaround.

Report · Apr 10, 2011

@ MojaMike: If it's any comfort to you long suffering Windows users out there, I have the same problem on my Mac when a card reader is connected; with or without a card in it, I get the spinning beach ball. I haven't bothered waiting to see how long it takes for the hang to pass; it's not worth the trouble to me. Since I have an external card reader I can disconnect it so that it doesn't impact Lightroom. Which means I cannot, and will not use Lightroom to download images from a memory card. For all intents and purposes, in my opinion, the feature is broken in Lightroom 3.3. My workaround is to use another app to download images from memory cards (Image Capture, which comes on every Mac, does very well, enabling me to direct the files wherever I wish to keep them).

I can't help wondering how long it will take Adobe to fix this card reader bug, or if they will even try. I guess I'll file another bug report just to say I've done my part to address the problem.

Report · Apr 10, 2011

Well, while some card readers may have problems, I can only say that on my machine (Windows 7, 64-bit, i5-750 CPU, Lightroom 3.4 RC), the import dialog appears without delay. No spinning no waiting, nothing. Thus I don't think that the import feature is generally broken, it is probably an issue between Lightroom and some hardware / driver stuff. Certainly not easy to detect and fix.

My card is a SanDisk Extreme III 16 GB SDHC, formatted in the camera (Lumix GH2). Did somebody, who has the problem, try with different cards, formatted in different cameras? I remember that in LR 2.3(?) - I can't remember the exact version - Lumix G1 raw files caused the Lightroom import dialog (the old dialog version) to react very slow, while raw files from Canon (CR2) did not show any problem. Adobe fixed the bug after two minor releases. There was no reason given, if the problem was caused by Lightroom code or by some unexpected changes in the .rw2 raw format. That time not all people had the same problems with G1 files and in my case the problem did only occur, when previews were on.

Does the problems occur also with the small version of the import dialog without previews?

Kind regards

Thomas

Report · Apr 10, 2011

MojaMike wrote:

"And after I reconnct the card reader to my motherboard, I get the big delay with the import screen again. How does that make any sense?"

What are your settings for Autoplay for the card reader?

On all my drives - including the card reader - I have Autoplay disabled, i.e. it is set to "Take no Action".

WW

Report · Apr 09, 2011

Hi,

Here is a copy of a report that I just sent to Dan after I had new LR performance issues on my system. I'm wondering whether other users have the same feeling and are observing the same symptoms...

I recently worked on a few images in LR (3.3) that needed lens corrections (mainly vertical and horizontal transforms) beside the usual corrections. While I was trying to set the relevant sliders, LR suddenly started to misbehave, slowing down to the point where it was totally unresponsive and unusable, displaying blank screens for a while, etc.

I copied the RAW file and the XMP file to another folder and loaded the image in Camera Raw. Working there and trying to apply the very same corrections was a much smoother process. No slowing down, no misbehavior. Well, transforming a rather big image takes time but at least I could do the job without any particular problem.

Not a new topic but I was again wondering why there are so much performance inconsistencies beween LR and ACR. Then I noticed that the ACR and LR user interfaces are actually not working the same way. For example, when I move the horizontal transform slider in ACR, it seems that ACR stops any computation until it detects that the slider is no longer moving. In LR, it seems that these computations occur continuously. That is, as soon as the slider value is changed a new computation is started. But the user can still increase or decrease the value while LR computes the new image. As soon as this computation is terminated, LR detects that a new value has been set and starts again. Meanwhile, the user can set a new value for the slider, etc. I don't know if I am clear enough but I guess you see what I mean. ACR obviously doesn't behave this way.

My feeling is that LR doesn't have an internal flag telling him that the current computation is no longer valid and has to be stopped because the user has changed the slider value anyway. It seems that ACR has such a mechanism. Otherwise I cannot understand why ACR runs much more smoothly when doing exactly the same job as LR. Moreover, if these transform computations are managed in a queue and if any change in the slider value adds a new entry to the queue (thus generating a number of useless jobs), I can understand why LR becomes unresponsive : a lot of unnecessary jobs are stacking up in the queue and are executed while they should be invalidated each time the user changes the slider value. Just a guess but there must be an explanation anyway...

Hope this helps.

Report · Apr 09, 2011

Samoreen wrote:
Hi,
Here is a copy of a report that I just sent to Dan after I had new LR performance issues on my system. I'm wondering whether other users have the same feeling and are observing the same symptoms...
I recently worked on a few images in LR (3.3) that needed lens corrections (mainly vertical and horizontal transforms) beside the usual corrections. While I was trying to set the relevant sliders, LR suddenly started to misbehave, slowing down to the point where it was totally unresponsive and unusable, displaying blank screens for a while, etc.
I copied the RAW file and the XMP file to another folder and loaded the image in Camera Raw. Working there and trying to apply the very same corrections was a much smoother process. No slowing down, no misbehavior. Well, transforming a rather big image takes time but at least I could do the job without any particular problem.
Not a new topic but I was again wondering why there are so much performance inconsistencies beween LR and ACR. Then I noticed that the ACR and LR user interfaces are actually not working the same way. For example, when I move the horizontal transform slider in ACR, it seems that ACR stops any computation until it detects that the slider is no longer moving. In LR, it seems that these computations occur continuously. That is, as soon as the slider value is changed a new computation is started. But the user can still increase or decrease the value while LR computes the new image. As soon as this computation is terminated, LR detects that a new value has been set and starts again. Meanwhile, the user can set a new value for the slider, etc. I don't know if I am clear enough but I guess you see what I mean. ACR obviously doesn't behave this way.
My feeling is that LR doesn't have an internal flag telling him that the current computation is no longer valid and has to be stopped because the user has changed the slider value anyway. It seems that ACR has such a mechanism. Otherwise I cannot understand why ACR runs much more smoothly when doing exactly the same job as LR. Moreover, if these transform computations are managed in a queue and if any change in the slider value adds a new entry to the queue (thus generating a number of useless jobs), I can understand why LR becomes unresponsive : a lot of unnecessary jobs are stacking up in the queue and are executed while they should be invalidated each time the user changes the slider value. Just a guess but there must be an explanation anyway...
Hope this helps.

That seems to make sense. I haven't tested with ACR but can confirm the behaviour in LR3.4RC

Report · Apr 10, 2011

Hi,

I recently worked on a few images in LR (3.3) that needed lens corrections (mainly vertical and horizontal transforms) beside the usual corrections. While I was trying to set the relevant sliders, LR suddenly started to misbehave, slowing down to the point where it was totally unresponsive and unusable, displaying blank screens for a while, etc.

I eventually installed version 3.4 RC. Not only this didn't fix the performance problems mentioned above, but the problems with the temporary blank screens and weird display behavior are now even worse. A problem that I occasionally had with LR 3.3 now appears more systematically : the second display is regularly disabled, generally while the main display is going nuts...

Again, I don't have and never had such slowdown and display problems when developing RAW files in Camera RAW or handling them in Photoshop (CS5). Ditto for LR 2.x. I'm wondering why it's so difficult to list the process differences between RAW file processing in ACR and in LR. ACR is dramatically faster (same system, same files). This eliminates any hardware configuration problem and any display driver or OS related issue. Since there's obviously a big difference, it should be easy to spot. Actually, there are 3 kinds of things to list :

1. the processing differences.

2. the additional tasks that LR is handling during development.

3. the user interface differences between LR and ACR.

Regarding #2, I only see the following:

- Catalog updating (I'm not writing to the XMP file automatically). So SQLite could be a potential culprit.

- Second display refreshing (although I have the same problems when using a single display).

I'm now considering switching to Bridge + ACR + PS. LR is not helping me. It is consuming my time.

Report · Apr 14, 2011

Samoreen wrote:
Hi,
I recently worked on a few images in LR (3.3) that needed lens corrections (mainly vertical and horizontal transforms) beside the usual corrections. While I was trying to set the relevant sliders, LR suddenly started to misbehave, slowing down to the point where it was totally unresponsive and unusable, displaying blank screens for a while, etc.
I eventually installed version 3.4 RC. Not only this didn't fix the performance problems mentioned above, but the problems with the temporary blank screens and weird display behavior are now even worse. A problem that I occasionally had with LR 3.3 now appears more systematically : the second display is regularly disabled, generally while the main display is going nuts...
Again, I don't have and never had such slowdown and display problems when developing RAW files in Camera RAW or handling them in Photoshop (CS5). Ditto for LR 2.x. I'm wondering why it's so difficult to list the process differences between RAW file processing in ACR and in LR. ACR is dramatically faster (same system, same files). This eliminates any hardware configuration problem and any display driver or OS related issue. Since there's obviously a big difference, it should be easy to spot. Actually, there are 3 kinds of things to list :
1. the processing differences.
...

Hi,

After discussing the problem with Dan, I discovered that disabling the local adjustments (by flipping the switch located in the brush adjustments panel) eliminates the slowdown problem in the lens corrections panel. So one could think that the transform adjustements should be done first (before the local adjustments) but unfortunately, if this speeds up the transforms, local adjustments then become slow if the lens corrections remain enabled. Kind of a chicken-egg problem...

Report · Apr 14, 2011

It's a bugger ain't it?

I've tried doing the lens corrections, then the perspective corrections and then turning them off

Then doing and "dust spot" corrections and also turning them off and doing any additional edits and then finally turning all the "off" edits back on.

I'm resigned to 3.3 being ok and very pleased that I am not bug testing for adobe on 3.4RC.

RC = really cxxp??

hamish NIVEN photography on the move

Report · Apr 14, 2011

It's more like a Catch 22. On the up side, we can assume that if Dan knows about the problem it would follow that others at Adobe know about it too, presuming he doesn't keep such knowledge to himself. At the same time, if he's the only one working on the issue - in his spare time, as he says - I wouldn't hope to see it fixed any time soon. That's not meant to be a reflection on his skills, but rather a reasonable estimation of the resources necessary to resolve so fundamental a problem.

Report · Apr 14, 2011

thewhitedog wrote:
It's more like a Catch 22. On the up side, we can assume that if Dan knows about the problem it would follow that others at Adobe know about it too, presuming he doesn't keep such knowledge to himself. At the same time, if he's the only one working on the issue - in his spare time, as he says - I wouldn't hope to see it fixed any time soon. That's not meant to be a reflection on his skills, but rather a reasonable estimation of the resources necessary to resolve so fundamental a problem.

Unfortunately, you use Dan's statements again to make assumptions about Adobe's bug analysis and fixing strategy, which is inappropriate. Software developers tend to experiment with stuff in their "free time" quite often, to improve what they do in their "official" time. This shows more the developer's eagerness to provide satisfactory results. To make the conclusion that it is Adobe's policy that such problem analysis and fixing is left for the developer's free time, is nothing you can conclude from Dan's statements, so it is better to leave such remarks out of the discussion. I don't say herewith that the Adobe's bug fixing policy is great, but the conclusions about individuals are out of order.

@ hamish niven: Additionally, some people tend to forget that 3.4 is release candidate, which meant to be test driven by the public in order to identify problems, which do not occur in Adobe's test systems. If people aren't willing to test drive the 3.4 RC "crap", fine, then it could be that their problems aren't known and fixed.

Instead of whining about possibly too early release of a release candidate, we should appreciate (and many people do this) that via early RCs, we can have new camera support much earlier (and test drive this too).

Kind regards

Thomas

Report · Apr 14, 2011

As a professional photographer why should I test the software? All have been invited to test it l and I take my hat off to those willing to do so.

My bugs from 3.3 have been reported by others and by me and I don't have the inclination or time to bug test 3.4. My comment about Really Crap releases was born of reading about the woes of many and so apologies to those it offends, but the general feeling seems to be that 3.4RC is not an improvement, and has upset many who generously gave their time to adobe to test it and they have suffered for doing so.

hamish NIVEN photography on the move

Report · Apr 14, 2011

hamish niven wrote:
As a professional photographer why should I test the software? All have been invited to test it l and I take my hat off to those willing to do so.
My bugs from 3.3 have been reported by others and by me and I don't have the inclination or time to bug test 3.4. My comment about Really Crap releases was born of reading about the woes of many and so apologies to those it offends, but the general feeling seems to be that 3.4RC is not an improvement, and has upset many who generously gave their time to adobe to test it and they have suffered for doing so.
hamish NIVEN photography on the move

I have no indication to assume that 3.4 RC is worse than its predecessors (some problems related to the GH2 profiles are actually solved), because it works without major flaws on my machine and is as stable as I am used to from Lightroom incl. most of the betas. Thus, it is wrong to claim that there is a *general* feeling than 3.4 RC isn't an improvement or even crap. *You* (and possibly a few others) have this feeling, which is fine.

It is also ok, that as a professional photgrapher, don't test the software. But then you should draw you conclusions from the final release and not from the RC.

I am not offended by your remarks, but I would rather pledge that Adobe releases betas or RCs even more often, which could improve the quality. However, if too many people then draw conclusiosn upon these pre-final versions and spread the message of non working RCs as if they were the final product, then the reaction of Adobe could even be that we will see less previews.

Report · Apr 14, 2011

@tguTgu - If it works without major flaws on your machine why are you even participating in this thread?

Your experience with it is that it is good, for others it clearly is not.

So what value do you bring to this thread? You have no experience of the problems people are facing so therefore can not suffer the pain or frustration that they are feeling. It appears you do not work for Adobe, so can not influence any corrective actions in the code or run debugging routines. And you cannot simulate the problems because you're not experiencing them...

Please leave this thread to those who do have a problem and wish to discuss it openly with others who may have a similar problem before bothering Adobe with a bug report. And for Adobe to determine by the volume of issues they see which area's they may be able to help with or fix.

Pretty simple really....

Phil

Report · Apr 14, 2011

@ tgutgu: In point of fact, despite your self-aggrandizing pretensions, you know no more about Adobe's efforts to fix bugs in Lightroom than I do. My conclusions about that effort are drawn from the empirical evidence clearly visible in the lack of substantial solutions to serious problems in the 3.4 RC and the more or less trivial nature of the items that were addressed. What Dan wrote merely confirmed what I already suspected in this regard. Thus your assumptions about how I arrived at my conclusions are mistaken and misdirected.

Your efforts to assert some kind of authority as the forum censor is what is inappropriate here. You are repeatedly driving the thread off topic with your unwarranted criticism of anyone who finds fault with Adobe. Given your own thread complaining at great length about a particular bug that concerns you, your censor here is nothing short of hypocrisy.

I don't know what you're trying to prove by endeavoring to shut other people down, but if you really cared a fig for anyone but yourself you'd get down off your high horse and find something constructive to say, as for instance I have done at great length in numerous posts over the last few months.

My apologies to everyone else for this rant, but tgutgu has become utterly insufferable - not to mention monotonous and boring.

Report · Apr 14, 2011

thewhitedog wrote:
@ tgutgu: In point of fact, despite your self-aggrandizing pretensions, you know no more about Adobe's efforts to fix bugs in Lightroom than I do. My conclusions about that effort are drawn from the empirical evidence clearly visible in the lack of substantial solutions to serious problems in the 3.4 RC and the more or less trivial nature of the items that were addressed. What Dan wrote merely confirmed what I already suspected in this regard. Thus your assumptions about how I arrived at my conclusions are mistaken and misdirected.
Your efforts to assert some kind of authority as the forum censor is what is inappropriate here. You are repeatedly driving the thread off topic with your unwarranted criticism of anyone who finds fault with Adobe. Given your own thread complaining at great length about a particular bug that concerns you, your censor here is nothing short of hypocrisy.
I don't know what you're trying to prove by endeavoring to shut other people down, but if you really cared a fig for anyone but yourself you'd get down off your high horse and find something constructive to say, as for instance I have done at great length in numerous posts over the last few months.
My apologies to everyone else for this rant, but tgutgu has become utterly insufferable - not to mention monotonous and boring.

I am sure that you don't get it, but don't you think it is better to leave the speculation about Dan's time schedule (which he probably regrets to have posted here), out of the discussion and concentrate on the subject?

Currently, we can't be sure, if he does not participate here, because he is fed up with the discussion about his remarks (which would not be a godd thing) or if he simply has no time or is on vacation.

I am not a censor and you can continue to post whatever you want, but I take and have the freedom to tell openly, if some remarks go too far in my opinion and if I think that they are actually counterproductive, if we expect help and more open communication with the Lightroom staff.

Report · Apr 14, 2011

tgutgu wrote:
thewhitedog wrote:
It's more like a Catch 22. On the up side, we can assume that if Dan knows about the problem it would follow that others at Adobe know about it too, presuming he doesn't keep such knowledge to himself. At the same time, if he's the only one working on the issue - in his spare time, as he says - I wouldn't hope to see it fixed any time soon. That's not meant to be a reflection on his skills, but rather a reasonable estimation of the resources necessary to resolve so fundamental a problem.
Unfortunately, you use Dan's statements again to make assumptions about Adobe's bug analysis and fixing strategy, which is inappropriate. Software developers tend to experiment with stuff in their "free time" quite often, to improve what they do in their "official" time. This shows more the developer's eagerness to provide satisfactory results. To make the conclusion that it is Adobe's policy that such problem analysis and fixing is left for the developer's free time, is nothing you can conclude from Dan's statements, so it is better to leave such remarks out of the discussion. I don't say herewith that the Adobe's bug fixing policy is great, but the conclusions about individuals are out of order.
@ hamish niven: Additionally, some people tend to forget that 3.4 is release candidate, which meant to be test driven by the public in order to identify problems, which do not occur in Adobe's test systems. If people aren't willing to test drive the 3.4 RC "crap", fine, then it could be that their problems aren't known and fixed.
Instead of whining about possibly too early release of a release candidate, we should appreciate (and many people do this) that via early RCs, we can have new camera support much earlier (and test drive this too).
Kind regards
Thomas

Perhaps a bit too strong on both counts Thomas. I think there is a side to both Whitedog's and Harmish Niven's comments. Given Dan's efforts here (and elsewhere), I think it is fairly safe to assume that as he (and others) find issues, that they make it known within the team. I'll agree that there is still a cost vs. time issue to be decided about the severity and potential for a fix that goes through a process, but I've no doubt the communication is there. These developers are split on multiple fronts. Working on existing bugs, planning additional point releases (if any - we know at least a 3.4), and probably well into a V4... There are all kinds of reasons why a known problem might not be fixed, despite Dan's efforts, until a new version.. these could include new designs required for whole sections of code. Might bandaids be available..maybe, but again, I'm fairly sure anything that Dan uncovers gets into a queue.

As for Harmish's comment.. I'm personally glad for the opportunity to try and test drive a new(er) release before hand, as time allows.. but Harmish's point is not without merit as well. Adobe, by this time, knows (or should know) what its baselines needs to be. I'm not saying that they have every machine in the world, but after this many turns of the crank, the basics (even for new functions) should be grounded on a solid platform.. a platform becomming more solid over time. That's a fair assumption by any user of a V3 of a product.. note I didn't say that was reality.. I just said it's a fair assumption. If someone is time constrained and can only devote some time to reading vs. playing, why should that person be faulted for not wanting to participat when they see many similar issues in the past already being raised? Does Adobe need one more voice to tip the scale to fix what has already been id'd as a problem?

I agree, that does leave the somewhat slim potential that some bug that mght only occur in Harmish's environment goes undiscoverd. Odds of that though are pretty slim as I said. I advovate everyone contributing what they can... but I'm not going to sit back and criticize them for choosing a different path.. they just frankly may not have the time and I respect that.

Jay S.

Report · Apr 14, 2011

Thank you JS in cape town.

I loved every minute of testing the original betas of LR, and some of the more recent ones.

I got burnt with the early versions of LR 2 and due to work constraints I've waited with baited breath and often delight for LR 3 and the dot releases, but not opted to be a tester.

I have enough speed and performance issues with 3.3 and reading the release notes for 3.4 I deemed there was very little that I would benefit from testing a mac with the RC, so I read and comment on 3.3 and on the feature requests for version 4 and beyond.

hamish NIVEN photography on the move

Report · Apr 14, 2011

hamish niven wrote:
Thank you JS in cape town.
I loved every minute of testing the original betas of LR, and some of the more recent ones.
I got burnt with the early versions of LR 2 and due to work constraints I've waited with baited breath and often delight for LR 3 and the dot releases, but not opted to be a tester.
I have enough speed and performance issues with 3.3 and reading the release notes for 3.4 I deemed there was very little that I would benefit from testing a mac with the RC, so I read and comment on 3.3 and on the feature requests for version 4 and beyond.
hamish NIVEN photography on the move

Hamish,

Nothing quite as exotic as Cape Town.. Connecticut is more like it. 🙂 but you're welcome. All that said, I did notice improvements on my Macbook Pro.. If you find yourself with a few cycles (and since we can run them side by side on the Mac) load it up and see if you get a little better performance out of it. There were fixes in the RC that didn't make the release notes, which was confirmed earlier in this thread.. but I understand the difficulty in "playing" or "testing" when you're trying to make a deadline.

Jay S.

Report · Apr 14, 2011

I, for one, could not recommend paying for another Lightroom upgrade until we know for sure that the most serious problems in version 3 have been taken care of - in version 3. Charging for a bug fix upgrade is unethical, to say the least, though it's not unheard of, even at Adobe. But a developer sullies their own reputation when they do so (Does anyone here remember Illustrator 9?). Nor are any new features likely to add much value when laid over an already unstable application. Instead, they can make troubleshooting and problem solving even more difficult and complex. One must assume that Adobe knows all this, but the Lightroom 3.4 RC certainly gives us reason to doubt they take the issues seriously.

Report · Apr 14, 2011

thewhitedog wrote:
I, for one, could not recommend paying for another Lightroom upgrade until we know for sure that the most serious problems in version 3 have been taken care of - in version 3. Charging for a bug fix upgrade is unethical, to say the least, though it's not unheard of, even at Adobe. But a developer sullies their own reputation when they do so (Does anyone here remember Illustrator 9?). Nor are any new features likely to add much value when laid over an already unstable application. Instead, they can make troubleshooting and problem solving even more difficult and complex. One must assume that Adobe knows all this, but the Lightroom 3.4 RC certainly gives us reason to doubt they take the issues seriously.

I'm with ya on this one.

I'm assuming Adobe won't give out any info on whether 3.4 is the last release before they work on 4.0...2.x went to 2.7 before they came out with 3, so I'm assuming there are a couple more updates to go which should give them (and us) opportunity to find out if they can make the app stable.

I miss 2.7, altho there are some aspects of 3 I would like if they could get it to run stable. I really don't need any bells and whistles, social media integration, etc. - I just need a stable app that will let us post process photographs which was what I thought was the whole intent of creating this app...

Report · Apr 10, 2011

web-weaver wrote:

> "What are your settings for Autoplay for the card reader?

> On all my drives - including the card reader - I have Autoplay disabled, i.e. it is set to

> "Take no Action"

I also have Autoplay disabled. As a test; I turned it on and had Pictures set to import into Lightroom 3, but that did not help either.

tgutgu wrote:

> Does the problems occur also with the small version of the import dialog without previews?

.

Yes. The problem still occurs with the small version of the import dialog.

But, I finally figured out a workaround for the performace issue on my system when importing to the Lightroom 3 library module. My 75-in-1 internal memory card reader (Rosewill - RCR-IM5001) sits in a 3.5" drive bay, on the front of my pc case. As it shows up in Vista as a 'USB Mass Storage Device', I can go into the Device Manager and set it to 'Disabled' before I click the import button in LR3. Thus, the import dialog pops on the screen very quickly, but without the drives that would have been available through the card reader. Later, I can go back into Device Manager and re-enable it.

I can live with this workaround for the time being. I usually copy my files from the card reader to my Photos folder beforehand, anyway. I just hope these import-related card reader issues get resolved sometime in Lightroom 3.x.

Thanks to everyone who replied here or posted about card reader issues in the other forum threads.

Report · Apr 15, 2011

OK, i've come back on because siunce the upgrade to LR3.3, my Mac has started grinding to a halt again in, and when trying to exit, develop module.

We're almost back to the same position as LR3.1 - and that almost forced me back to LR2!

It seems like plenty has been written, and i appreciate that various comp configs will affect how a prgoram works - but i'm puzzled by the fact that Mac's are, for the most part - all built to a same spec, where as Windows systems reqlly can vary from one pachine to another.

Sad things, my Mac is already maxed out at 4gb, and i'm in no hurry to ask for funds to upgrade to a model that can accomodate 16gb of ram - shouldn't need to...

Will have to keep an eye on this issue, and roll back to RC3.2 if a fix doesn't happen soon...

Report · Apr 15, 2011

Hi,

Pic4 wrote:
It seems like plenty has been written, and i appreciate that various comp configs will affect how a prgoram works - but i'm puzzled by the fact that Mac's are, for the most part - all built to a same spec, where as Windows systems reqlly can vary from one pachine to another.

Not sure whether this has already been discussed but I'm wondering whether these performance problems could be related to a specifc processor brand. I have recently read somewhere that Photoshop and Lightroom were optimized for Intel processors (which has to be confirmed). Maybe those who are experiencing performance issues could post what processor they are using?

I'm using an AMD Athlon 64 X2 Dual core 4400+, 2.21 GHz (XP Pro SP3 + 3 GB + NVidia GeForce 9500 GT / 1GB / dual screen).

Report · Apr 15, 2011

Macs switched to Intel processors five years ago. The first used, in 2006, was a Core Duo; the next year they began using the Intel Core 2 Duo. Any Mac with a capacity of 4GB of RAM likely uses the Core 2 Duo. Since Lightroom works just fine on most of these Macs, I doubt the CPU is the issue. But I agree we need to know more about Pic4's computer and the conditions under which Lightroom stalls out on him before we can offer anything more than guesses about what is causing Lightroom to stall out on him.

Adobe Community

Lightroom 3.3 Performance Feedback