Lightroom 3.3 Performance Feedback

[Tom Hogarty]

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

[Samoreen]

Samoreen wrote:

The call comes from substrate.dll (LR) => ValidateLocale (kernel32) => SetClientTimeZoneInformation (kernel32) => ntoskrnl.exe (kernel)

To be more accurate, there are 5 consecutive calls from substrate.dll before a call in kernel32 is made.

First call is made from address 48A8E (from lua_yield ?)

Next call from address 3F735 (from lua_call ?)

Next call from address 48833 (from lua_getinfo ?)

Next call from address 485FD (from lua_getinfo ?)

Next call from address 2A3A0 (from AgURIUtils_load_L ?)

These values are offsets from the loading address of substrate.dll which in my case is 602B0000. The function names are just guesses based on the address.

Hope this helps.

[DanTull]

Sorry for the delay, I just got back from holiday break.

Regarding the time zone registry reads, with an assist from one of the developers (who was also curious) I determined that the Windows native routine we use to convert a time value into its components (year, month, etc) reads this value from the registry. I have not, however, been able to reproduce the kind of machine gun access of those keys that you describe.

The code paths I found that access this are certain library filters for date/time values, XMP parsing/comparison and a couple of metadata formatters. I do get one call to that routine when I release the mouse after a brush stroke. That single call no longer occurs if I go to Library and change the grid view options (Ctrl + J brings up the dialog) so that capture time is not shown on grid cells. I also get the query if I use the I key while in loupe to flip between the different loupe info overlays.

The rate at which you are seeing it definitely suggests something in your situation is triggering a different series of events to occur than I'm seeing. Does the screen flicker as you mouse over (suggesting excessive re-painting) and is there anything unusual about your mouse (is it a tablet, do you have any usual settings for the cursor, etc)? Also, if you turn off the loupe overlay and set your grid to not show the capture time on each cell, do the calls stop? Lastly, do you have auto-write XMP enabled? (I haven't tried that yet, but the fact that the XMP/metadata code uses the time component call makes me suspect it).

Edit: Just reading through some of the other replies and already see that auto-write XMP is out (just found your resolution note about clearing out prefs and such, I'll have to see if the subsequent messages narrow the diagnosis a bit as this definitely seems like something worth understanding). Thanks for your persistence!

DT

[Samoreen]

Hi Dan,

DanTull wrote:

The rate at which you are seeing it definitely suggests something in your situation is triggering a different series of events to occur than I'm seeing. Does the screen flicker as you mouse over (suggesting excessive re-painting) and is there anything unusual about your mouse (is it a tablet, do you have any usual settings for the cursor, etc)? Also, if you turn off the loupe overlay and set your grid to not show the capture time on each cell, do the calls stop? Lastly, do you have auto-write XMP enabled? (I haven't tried that yet, but the fact that the XMP/metadata code uses the time component call makes me suspect it).

Since LR now works normally (and much faster) since I uninstalled/cleaned up the registry and the disk/re-installed, I may not be able to answer all questions but I'll try...

Does the screen flicker as you mouse over

No.

is there anything unusual about your mouse (is it a tablet

No. I have a tablet attached but the problem also happened without it being connected. It is still there however, and there's no problem with it. As mentioned in a previous message. I didn't change anything to my configuration during the uninstall/cleanup/reinstall process and I didn't even reboot. The problem was cured immediately. Since I only removed the LR related folders and registry keys, the problem may be caused by something that happens when upgrading from a previous version (although as I mentioned, 3.3 was installed in a new folder).

Also, if you turn off the loupe overlay and set your grid to not show the capture time on each cell, do the calls stop?

I can't say but the problem was only appearing when hovering the image editing area. The registry calls didn't occur when hovering any other area in LR (or any other application window not related to LR).

Lastly, do you have auto-write XMP enabled?

No. This option has always been disabled. I save the XMPs only when needed.

--

Patrick

[DanTull]

Wow. Thanks for the fast reply. I just caught up with the rest of the thread (glossing over the chatter as usual) and the only guess I have is that you mention there are discrepancies between your preferences file (I can't imagine that the presence/absence of the presets folders would have triggered this).

I'll send you a private message to get those preference files. Here's hoping there's a clue in there. I can confirm that certain preference changes do alter whether these accesses happen for me at all, but I have not yet been able to reproduce the ugly on hover access pattern.

As for anybody else on the thread using Windows and seeing performance problems in Develop, I'd be highly interested if any others are seeing this registry access frequency symptom as well (or not).

Thanks -- DT

[DanTull]

Aha. I found one way to make mouse over behavior in the develop loupe trigger at least some access to the time zone keys: if I turn on the secondary window (I'm not currently using a multi-monitor set up, though I'd expect having it on a second monitor would have the same behavior) via the "2" icon on the top edge of the left side of the filmstrip, I see a few time zone accesses occur during simple mouse over of the loupe view. It occurs whether the local correction tool is enabled or not and does not produce a terribly high volume, but it does trigger them fairly quickly and stops when I stop moving the mouse.

It persists even if I dismiss the secondary window, but if I quit and restart after dismissing it (so that I start up without the secondary window), it does not persist until I bring up that window again. It appears to occur regardless of which mode of the secondary window is active.

I'm not convinced that this is the whole bug, but it's my best lead at the moment. Given that there is a definite trend of people with multiple monitor setups having performance pain, it's certainly worth exploring a bit.

DT

[Ian Lyons]

DanTull wrote:

I'm not convinced that this is the whole bug, but it's my best lead at the moment. Given that there is a definite trend of people with multiple monitor setups having performance pain, it's certainly worth exploring a bit.

Dan,

I had a bug logged against red eye,  healing and adjustment brush performance that turned out to be linked to the secondary screen some months back. The worst excesses where fixed, but I was never advised in what way the two were linked. I also passed info to Julie re a scenario where the mere presence of a secondary screen connected to a computer, but not active in Lr, was enough to throw Lr into a tizzy when attempting to use healing or adjustment brush. So, it wouldn't be any surprise to me that there are more bugs lurking in the same place.

[PhilBurness]

One thing I have noticed since running RegMon on a Windows 7 Ultimate system is that wmpnetwk.exe is constantly accessing my images.....

Phil

[Samoreen]

DanTull wrote:

Also, if you turn off the loupe overlay and set your grid to not show the capture time on each cell, do the calls stop?

Since the registry calls problem is unfortunately (or fortunately?) back since today, I can now answer this question: removing the capture date/time from the overlay makes the problem disappear.

--

Patrick

[Samoreen]

Samoreen wrote:

DanTull wrote:

Also, if you turn off the loupe overlay and set your grid to not show the capture time on each cell, do the calls stop?

Since the registry calls problem is unfortunately (or fortunately?) back since today, I can now answer this question: removing the capture date/time from the overlay makes the problem disappear.

To be more accurate:

- Removing the capture date/time overlay in Loupe Mode makes the problem disappears.

- Using the Grid mode in the secondary window (instead of the Loupe mode) even if the thumbnail displays the capture date/time for each cell doesn't make the problem re-appear.

--

Patrick

[DanTull]

Though the release notes do not reflect it, 3.4 RC has a fix for this bug. The registry calls themselves from the time zone API were not terribly expensive and I wasn't able to reproduce any big slowdowns, but we did find some unnecessary work being done in the mouse move handler that fits the symptoms described.

I don't know if folks are still watching this thread, but I figured I'd reply to it for the record and all.

DT

[PhilBurness]

Dan,

Glad you fed this back here, I will now try 3.4 RC1 (I wasn't going to because the release notes didn't indicate anything was done in this area), I will feed back my comments here.

Best Regards & Thanks

Phil

[Shocker2000]

Dan,

I'm been trying to use 3.4 RC all afternoon - it is painful. It took 3 tries to perform an import of 583 photos. Several hours now. It takes an hour to generate previews. During the import the computer becomes unresponsive - full CPU for an import? On the first import I got 250 photos and 25 minutes to render standard previews. There is no percent completion for import unless you switch to another app. Pretty rough...

Mark

[JayS_In_CT]

Shocker2000 wrote:

Dan,

I'm been trying to use 3.4 RC all afternoon - it is painful. It took 3 tries to perform an import of 583 photos. Several hours now. It takes an hour to generate previews. During the import the computer becomes unresponsive - full CPU for an import? On the first import I got 250 photos and 25 minutes to render standard previews. There is no percent completion for import unless you switch to another app. Pretty rough...

Mark

Mark,

Perhaps worthy of a new thread on 3.4RC?  Are you on Windows? Mac? New catalog, adding to existing?

Jay S.

[Shocker2000]

Windows Vista 64-bit.

I never create a catalog. I import, work on the images and export. I guess this would qualify as "new".

I restarted my machine. Hopefully the processing will work better now that I have the images imported.

Thanks

Mark

[thewhitedog]

You may not have knowingly created a catalog, but you did so with the first import to Lightroom. This catalog is updated with each subsequent import. Exporting images does not remove them from the Lightroom catalog, it merely moves copies to another location of your choice.

[DanTull]

I'm been trying to use 3.4 RC all afternoon - it is painful. It took 3 tries to perform an import of 583 photos. Several hours now. It takes an hour to generate previews. During the import the computer becomes unresponsive - full CPU for an import? On the first import I got 250 photos and 25 minutes to render standard previews. There is no percent completion for import unless you switch to another app. Pretty rough...

Strange. I don't know of any changes that I'd expect could have that effect on import. As noted by Jay, this is probably worthy of a new thread.

Here's the additional info to provide as well:
- exactly how are you importing (add from folder, copy, move, convert to DNG?)

- in the case of copy/convert/move what are the source and destination volumes?

- what are all the other options for the import (secondary backup, rename, etc)

- exactly what kind of photos are they and are there any existing adjustments?

- have you done exactly this import with 3.3 and has anything else changed besides moving to 3.4?

- can you post the contents of the system info dialog in the help menu (be sure to remove your serial number from the copied output before posting)

- it sounds like you're seeing lots of CPU usage (in task manager)? What other data does task manager show?

Also, if anybody else has seen anything similar, the same battery of questions applies and it'd be interesting to get more info. On a new thread, preferably so we can keep import similar symptoms together instead of in (yet another) dogpile thread.

Thanks -- DT

[thewhitedog]

I'd be glad to post to a new thread about the new Lightroom RC, but am reluctant to start one; I think I should leave that to the old hands or Adobe staff. But I already have an issue with the RC and have just stopped using it as a result. I find, on my 3GHz quad core Mac Pro with OS X 10.6.6, 8GB of RAM, that the arrow keys don't work in the adjustment brush to move the sliders. It's a total deal breaker for me, as I primarily use the arrow keys to fine tune my adjustments.

[web-weaver]

thewhitedog wrote:

function(){return A.apply(null,[this].concat($A(arguments)))}

that the arrow keys don't work in the adjustment brush to move the sliders.

I can confirm that. In my LR 3.4 none of the sliders of the Adjustment Brush can be moved with the arrow keys. The same goes for the sliders in the Grad Filter: arrows won't work here either.

My OS is Win XP SP3.

You can log a bug report here

https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform

WW

[JayS_In_CT]

web-weaver wrote:

thewhitedog wrote:

function(){return A.apply(null,[this].concat($A(arguments)))}

function(){return A.apply(null,[this].concat($A(arguments)))}

that the arrow keys don't work in the adjustment brush to move the sliders.

I can confirm that. In my LR 3.4 none of the sliders of the Adjustment Brush can be moved with the arrow keys. The same goes for the sliders in the Grad Filter: arrows won't work here either.

My OS is Win XP SP3.

You can log a bug report here

https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform

WW

I don't remember up / down ever working for that function, only left / right arrow keys.  Does the "mouse drag" left / right still work?  How does something like this happen, that keystrokes stop working..  Sometimes it's just plain scary..  Is someone writing it up so it can hopefully get fixed before 3.4 final?

Jay S.

[web-weaver]

In addition to my earlier note:

I just discovered that Shift + Up/Down Arrow works with the sliders of Adjustment Brush and of Graduated Filter and changes the values in increments of 10 - as expected. But Up/Down Arrow alone does not change the values of any sliders. Left /Right arrows does not do anything - but that's expected.

WW

PS: I reported it as a bug. But I urge you to do it, too.

If this behaviour is reported for different OS, then only LR can be causing this.

[JayS_In_CT]

web-weaver wrote:

In addition to my earlier note:

I just discovered that Shift + Up/Down Arrow works with the sliders of Adjustment Brush and of Graduated Filter and changes the values in increments of 10 - as expected. But Up/Down Arrow alone does not change the values of any sliders. Left /Right arrows does not do anything - but that's expected.

WW

PS: I reported it as a bug. But I urge you to do it, too.

If this behaviour is reported for different OS, then only LR can be causing this.

Yeah.. sorry for the typo above..  I meant left / right don't do anything and up / down were the change elements.  Odd that the Shift+up/down work (even if in larger increments) but not stand alone.

Jay S.

[thewhitedog]

@ web-weaver: the up and down arrow keys have always moved the sliders in earlier versions of Lightroom when you hover the cursor over the slider so that the numerical field is highlighted slightly in gray to indicate you are in the target area. They still do this in the other palettes but no longer work in the Adjustment Brush and the Graduated Filter - except for Exposure.

I filed a bug report using the link you provided. I'm using a 3GHz quad-core Mac Pro running OS X 10.6.6 with 8GB of RAM. As I said, I use the arrow keys regularly; the loss of this function is a deal breaker for me and I have stopped using the Lightroom 3.4 RC.

On another note, I noticed no improvement in performance with the RC. Whatever was slow in Lightroom 3.3 is still much the same, from importing and exporting to drawing thumbnails and switching images. The only improvement I noticed was in the use of the adjustment brush; Lightroom 3.4 RC did not freeze up on me after awhile like version 3.3 always did. But then I've stopped testing because of the arrow key bug, so my conclusion is only preliminary after a moderate amount of use and may not be accurate.

I find it discouraging that after many months and two lengthy threads discussing performance problems with Lightroom 3.3, none of the issues we talked about at such great length seem to have been addressed. I guess the Adobe engineers spent all this time dealing with low hanging fruit, mostly problems I've never heard of to judge by what they chose to mention in the release notes for the RC. Up till now I've been willing to give them the benefit of the doubt that they take our problems seriously; however, at this point I can't help feeling that my patience has been abused and my trust has been in vain. Not only have they not fixed the performance problems, they've introduced new bugs to important features. Color me gravely disappointed.

[Guest]

Just see the thread about bug fixing policy. Adobe does not even dare to comment on this.

To me, "product maintencance" is on very low priority with them - not very professional.

Thomas

[dougryan]

I can't even say how much this is bumming me out. When I started using LR a few years ago, I had been comparing it with Aperture, since I'm an OS X user. Aperture had been incredibly buggy and slow to the point of not being able to do anything unless you waited for beach balls to disappear. I don't know when things got so bad, but it seems that the tide has turned, completely. I'm testing Aperture again, and it now reminds me of what LR USED TO be like. This is aside from the fact that Aperture is now $79, the fact that its brushes completely CRUSH anything that the LR adjustment brush can do (omg the clone brush is amazing !   )

I'm trying to justify continuing on with LR at this point. Only one or two things do this for me. Noise reduction, sharpening and the overall means of organization. I hate Aperture's albums/projects concept. I also much prefer LR's export options. But I dunno... I can't use the tools which make LR what it is.. .The gradient tool gets my system way hot and bothered.. Just before I was typing this, I was going through develop presets for a portrait, and it was taking anywhere between 4-8 seconds in order for the changes to take place. This has NEVER happened in the few years I've been using LR, and it's making me really sick to my stomach to see this happen.

Granted, I don't have a brand new system anymore, ( MacBook Pro 2.4Ghz with 4 gigs of RAM) but this was never an issue. Seems to me that maintenance has truly taken a back seat, as new code gets tossed in, leaving old and irrelevant code in bloating things up to heck. I never understand why software companies never take the time to optimize the code for updated software releases, rather than just piling on more and more stuff. That said, what ever Apple have done in order to spruce up Aperture 3.1.1's performance, it sure as heck ain't what Adobe is doing, and that apparently, is a GOOD thing.

Adobe, get your priorities STRAIGHT please! Photographers don't care about Facebook plugins...  I could see taking a hit in performance with things like the clone brush tools that Aperture has... But if this is because of the new algorithms, I'd rather go back to the old process, personally speaking. At least I was able to work in a timely fashion.

For the time being, I'm afraid that I can no longer recommend LR over Aperture. How things have changed !

Doug

[thewhitedog]

I guess Adobe was ashamed of providing bad performance only on the PC side of Lightroom 3 and decided to balance things out by degrading and buggifying the Mac version in the latest RC. Fortunately, Lightroom 3.3 is still fairly stable on the Mac so I'm sticking with that for the time being. I sent in an official bug report for 3.4 RC and, of course, have had no reply. With no acknowledgement on this thread, nor announcement of a new thread for the new RC it appears Adobe staff are too embarrassed to show their faces on their own forums. I can't say I blame them.