Lightroom 3.3 Performance Feedback
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
I've decided Lightroom 3.3 is just obnoxiously slow.
In Library mode it is taking a couple of seconds to switch between images. That just ain't right. This is on an internal SATA drive. LR 3.2 never behaved like this (again: LIBRARY mode, lest anyone think it was a typo).
Copy link to clipboard
Copied
I have the feeling sometimes Lr does not use the previews when it should. I've experienced blazing fast switching when things are being pulled from the cache the way they should (small fraction of a second), but sometimes there are re-rendering lags (2-3 seconds) when it seems like the photo should have been pulled from the preview cache. I haven't studied this too rigorously, but I've certainly noticed it.
Lightroom version: 3.3 [711369]
Operating system: Windows 7 Ultimate Edition
Version: 6.1 [7600]
Application architecture: x64
System architecture: x64
Physical processor count: 4
Processor speed: 3.4 GHz
Built-in memory: 7934.1 MB
Real memory available to Lightroom: 7934.1 MB
Real memory used by Lightroom: 837.9 MB (10.5%)
Virtual memory used by Lightroom: 1011.0 MB
Memory cache size: 512.5 MB
System DPI setting: 96 DPI
Desktop composition enabled: Yes
Displays: 1) 1920x1200, 2) 1920x1200
Copy link to clipboard
Copied
Lightroom 3.3 performs adequately on my three year old 3GHz quad-core Mac Pro with 8GB of RAM and OS X 10.6.5. My concern is that it does less well for what is apparently a significant sub-set of users, who report their issues on these forums. I spent very little time here before I started using the Lightroom 3 beta so I don't know if there was a similar volume of problem reports for earlier versions - with which I had few issues personally (and I've been using Lightroom since it became available in the first beta program). Indeed, it was that beta program that hooked me on Lightroom, so that I absolutely had to buy the release version.
What seems clear to me, though, is that Adobe made significant changes to version 3, many of which impact performance. So though the code was optimized and made 64 bit capable, overall performance seems not to have improved. Which means Adobe did over-promise when promoting Lightroom 3 - which has led to disappointed expectations. Even though I'm having no problems myself, I cannot help feeling the pain of those who are. And I wonder why they are having these problems with what should be, by now, a fairly mature and stable product.
Despite my original surmise, hardware seems not be a central issue. My own computer is hardly the newest, though it's still a very capable machine - which is why I got a Mac Pro in the first place. Yet people with hardware far superior to mine are having more trouble than I am. This is a puzzle for which I see no solution as yet. There are things you can do, as I have suggested, that will improve the program's performance, yet the problems people are having seem to go beyond these manageable variables.
I can only hope that Adobe is having some success in finding the bottlenecks that are causing so much grief among their users. And that they will, sooner or later, resolve these issues - before adding any new functionality to the program that will inevitably cause yet another round of trouble.
Copy link to clipboard
Copied
When Lightroom is functioning unencumbered, Machine power makes all the difference in the world, however if you're being bit by a bug that keeps your hungry machine waiting, it doesn't matter how hungry it is...
Copy link to clipboard
Copied
dwterry wrote:
I've decided Lightroom 3.3 is just obnoxiously slow.
In Library mode it is taking a couple of seconds to switch between images. That just ain't right. This is on an internal SATA drive. LR 3.2 never behaved like this (again: LIBRARY mode, lest anyone think it was a typo).
Are you talking about 1:1 or fit mode? In fit mode, I have no issues going image to image with standard size previews built. What settings do you have for Previews on import, cache, etc. I'm on an older Macbook Pro. I've got other performance related issues but this isn't one.
Jay S.
Copy link to clipboard
Copied
AHA! I found the solution to my performance issues. I promise ... I didn't do it.
The cache size was set to just 1.0 GB. It's not a setting I look at .... ever. If I ever set it ... it was probably clear back in LR 1.x or early LR 2.x days, certainly it wasn't something I set in recent times. When/if I did set it, I seriously doubt I picked 1.0 GB (that just seems terribly small to me, when I regularly shoot over 16GB per photo session). And I definitely did *not* set it when LR 3.3 came out (and the catalog I am using today was first started when LR 2.0 came out and simply upgraded by LR over time).
So I wonder .... did installing LR 3.3 over top of my LR 3.2 cause the cache setting to change?
I know you'll say it shouldn't have, but the performance for me definitely dropped as a result of installing LR 3.3.
Anyway, I'm back to being a happy camper. I get lightning fast switches between images in library mode again.
Copy link to clipboard
Copied
Are you talking about the Camera Raw Cache Settings (under Preferences -> File Handling)? If so, those shouldn't affect
Library mode performance- just Develop mode.
Its the Preview Cache settings (under Catalog Settings -> File Handling) that determine Library mode performance, or at least that's how its supposed to work. And you want standard size to be set at least as wide as your monitor. I set preview quality to 'Medium' which takes a bit longer to compute initially but is not noticeably slower to load from cache than the 'Low' quality preview. And set discard 1:1 Previews to "Never". I can tell the difference between Low quality and Medium, although Low isn't that Low at all. But, my crude eye can tell little difference between Medium and High.
If changing the ACR cache size seemed to have affected Library switching speed, it may have been a "Red Herring". - Try setting it back to 1G to test that hypothesis...
Rob
Copy link to clipboard
Copied
I disagree with Rob's suggestion that you need to set the preview size to at least as wide as your monitor. Whether that's optimal or not will depend on how you use Lightroom. If you regularly view images with all the panels, top and sides, hidden, then a large preview size can save a bit on rendering time. On the other hand, if you generally - as I do - leave the panels showing, a smaller preview size will be adequate. It's really a workflow issue and the right answer depends on your workflow preferences.
Copy link to clipboard
Copied
Ok - you caught me oversimplifying...
If Lightroom needs something bigger than what it has for the square you are trying to display in, then it has to create it (ignoring zoom issues for now).
So, if you never view loupe (fit-view) without panels, then 1680 is enough for a 1920 display. If however you want the option to nix all the panels and view without re-rendering, then its not enough - in which case you need something very near the width of your display - the exact number can be obtained by subtracting the mandatory border size...
As an exercise to test your understanding, ask yourself now if a 1680 preview would be big enough for fill-view (on that 1920 monitor that is) - with panels?, without panels??
My previous "recomendation" was based on maximizing switching performance (allowing for fill-view and/or panel-less viewing). If there weren't other potential considerations, then Adobe would just pick the size for you based on actual monitor dimensions...
Note: If you keep 1:1 previews for everything, then it does not matter what you set standard preview size to. I'm assuming Lr will just render the largest it needs on demand, rather than the whole standard preview set, when a non 1:1 library view is requested and develop settings have changed, and that the whole standard preview set is only rendered upon import (assuming standard previews are being included) or menu selection - but I don't know if that is true or not.
Rob
Copy link to clipboard
Copied
For me there is also some confusion about the difference between the preview size you specify in the import dialog and that set in Catalog Settings>File Handling. They don't seem to be equivalent, which suggests, to me, that they refer to different iterations of the previews. There is some logic to this somewhere, but it eludes me.
Copy link to clipboard
Copied
Probably ought to start a new thread with that one...
Copy link to clipboard
Copied
As you can see from my previous post, I found the threads that already exist on the subject - and provided links to them. Questions about catalogs and previews keep coming up on this thread, indicating that some of us at least don't fully understand what Lightroom does and how this affects performance. Some additional clarity on these issues may help those with performance problems resolve their issues. That is my hope, anyway. The size of the RAW cache may be one of the most significant, for instance.
Copy link to clipboard
Copied
Just realize that the ACR cache is for develop mode only, and the previews are used primarily for Library views. So cache size has nothing to do with library performance. Likewise, previews have little to do with develop mode performance.
Copy link to clipboard
Copied
OK, after doing some digging on the Adobe Lightroom forums, I came up with the following information, in summary: the preview size and quality you select in Catalog Settings>File Handling determines the size of the Standard preview rendered on import. Here are a couple of posts by Ian Lyons that explain the preview creation and utilization process fairly well: Why is the Lightroom preview folder so big, even after purging the 1:1 previews? and Can Lightroom render 1:1 Previews when importing my Photos?. Lyons is a Community Professional with over five thousand posts on the forums. In these articles he supports what Rob said about using a standard preview size equal to or greater than your monitor's width in pixels, in order to save rendering time later.
On this forum thread, Speed - Preview Size and Library Thumbnails, Ian is joined by another Community Professional, Seán McCormack, in answering questions related to the catalog settings and previews. I recommend these items to all those posting here who, like me, have been confused about these issues. While they might not resolve all the performance problems people are having, they do explain what Lightroom does and why. Understanding these features might make it easier to adjust your settings - and your expectations - more effectively to meet your individual workflow needs.
One point I saw verified is that the RAW cache is set to 1GB by default. This is almost certainly too small for efficient processing of RAW images in Lightroom. For this reason, I use a large hard drive with plenty of fee space for my cache, which I have set to 10GB. For those with thousands of images even this may be too small. When the cache fills up, the oldest files are purged to make room for new ones. If you return to an image that has been purged from the cache, Lightroom has to render it again, which can slow it down significantly. I was also interested to learn that, even if you select the Minimal or Embedded & Sidecar preview size in order to import images more quickly, Lightroom will still have to render a Standard preview whenever you view these files. To quote Ian: "Minimal (Lightroom default) or Embedded & Sidecar is by far the quickest method for getting your photos into the Lightroom catalog. However, the lack of Standard, which is the minimum that Lightroom can actually work with, means that the application will render standard-sized on demand (i.e. as thumbs/photos become visible within the photo Content area). Asking Lightroom to undertake this task at the same time as you're trying to use the application will result in sub optimal performance." Alternatively, you can import the smaller previews and, in the Library module, under the Library menu, in the Preview fly-out menu you can choose to render standard or 1:1 previews post import. The advantage here might be that you can apply this render to a select group of images rather than to all the files you imported. Again, this is a workflow related decision. The right answer for you may be different from the right answer for someone with different workflow priorities.
Copy link to clipboard
Copied
thewhitedog wrote:
One point I saw verified is that the RAW cache is set to 1GB by default. This is almost certainly too small for efficient processing of RAW images in Lightroom.
Despite what community professionals have said about the ACR Cache storing "previews", to the best of my knowledge (which I acquired on this forum from community professionals), increasing the ACR Cache is not the key to dramatically increase performance.
The ACR Cache only stores a pre-stage for the final rendering of the image (the demosaiced RAW data). Hence, while it saves a bit of processing time to be able to access this stage directly, rather than having to compute it, the bulk of the time spend in rendering an image in the Develop mode is spend on replaying all edit operations.
You can easily verify this. If there are no edit operations, rendering of the image finishes the quickest. This is the case were availability of a pre-rendering in the ACR Cache will be most noticeable. If there are a lot of edit operations (lots of brush applications and spot removals) then rendering the image (to its final stage, not just showing the preview that is shown in the Library module as well) will take a lot longer. In this case, the availability of having the pre-rendered version available is almost inconsequential as the savings pale in comparison to the time spend on replaying the edit operations.
In other words, the ACR cache
- only affects image rendering in the Develop module
- has little impact on overall image rendering times
- procudes savings that are next to neglible for images that received a lot of edits
- doesn't need to be huge.
Regarding 4: You'll never be able to set the size such that LR can always access a pre-rendered version. It is all about having sufficiently many available for a given editing session. If you only work with 50 images during one session, you don't need a cache that deals with 1000 of images. Throwing out old images and replacing them with new ones in the cache doesn't take long. Hence it isn't a problem to have a smallish cache as long as it is sufficient for single editing sessions. The reason why it doesn't take long to replace entries in the cache is that not much work is being saved anyhow.
I hope this helps to demystify the role and significance of the ACR Cache.
Copy link to clipboard
Copied
TK2142 wrote:
You can easily verify this...
You can also verify this by simply looking at the size of the entry in the cache - its always the same for a given image, independent of editing.
It wouldn't surprise me if the data in the cache file was exactly the same too (for a given image, independent of editing) - although I haven't checked it.
Also, as you edit, the cache file last-modified-date does not change - more proof that the cache entry is a baseline...
PS - Although, it has been pointed out in a previous thread that an application could use abnormal disk IO techniques for updating this entry which circumvent date-modified and keep the file size the same, given everything else (how it behaves - as you've pointed out...) - that is not the case.
_R
Copy link to clipboard
Copied
OK, so the "community professionals" disagree on the importance of the Raw Cache size. What are we to make of that? Pick you poison. The same "professional" I quoted on the Raw Cache verified Rob's point about the importance of setting large enough preview sizes. Was he wrong about that, too? How are we to know?
Dueling authorities don't help us much. In the end we are still left to stumble our own way to a solution - or not. At least I actually quoted and provided links to the sources I was using. We can only trust that TK2142 remembers his sources' comments correctly, since he gives us no way to verify his information. This doesn't make him wrong, of course, but it doesn't make him right either. At best it's a toss up.
As for his helping "to demystify the role and significance of the ACR Cache," I'd say not so much. In fact, it wasn't clear we were even talking about the same thing. ACR refers to Adobe Camera Raw, which is a Photoshop plug-in more or less comparable to Lightroom. As it happens, I just checked, and Photoshop and Lightroom use the same Raw Cache folder (as does Bridge); if you change the cache in one program it will automatically change it in the others. Still, in the Lightroom preferences it is referred to as Camera Raw Cache; in Photoshop's Camera Raw preferences it's also called the Camera Raw Cache, and in Bridge as well. So it would appear that his use of the term ACR Cache is, at best, imprecise and, at worst, misleading. As a result I have to say, before TK2142 can "demystify" anything he needs to get his terminology straight. He may still be correct about the relative importance of the Camera Raw Cache, but before we can accept that he knows what he's talking about, we need some indication that he does, in fact, know what he's talking about. By mislabelling the folder at the very center of the discussion, and neglecting to reference the sources he cites, he undermines his own credibility, at least to some degree.
The biggest problem with his demystifying, though, is that he uses straw man arguments to make himself look good. No one I read or quoted said anything about making the Raw Cache large enough "such that LR can always access a pre-rendered version." As a result, debunking his argument is quite simple: a small cache will retain a small number of images; a large cache will retain substantially more. How big the cache should be depends on your individual workflow, not on some mythical "always." And how much the cache size affects your efficiency depends on how you divide your time between the Library module, where the Raw Cache has no significant role, and the Develop module where it plays a larger part. By glossing over these distinctions, TK2142 attempts to diminish the importance of the Raw Cache, but the gloss merely adds more imprecision to his arguments.
For most of us, the challenge in Lightroom performance is to adjust the settings we use to enable us to work as efficiently as possible, given our individual needs and preferences. Arguments about the relative importance of something like the Camera Raw Cache are themselves relative, especially if we accept that the "experts" disagree. While it's possible to glean a few grains of truth from TK2142's discussion, it's far more difficult than it needs to be. Given that I claim no particular expertise of my own (hence my references to those far more well informed than I), it's not clear who he's contending against. Argument for its own sake, perhaps?
This is precisely the kind of dissension that undermined the earlier thread on the same subject (Lightroom 3 performance problems). Perhaps I should have left TK2142's remarks alone (and I'll no doubt hear from you all if that's so), but they muddied things up so dramatically that, in my opinion, at the risk of some contention, they should not be allowed to go unchallenged. If he has some credible authority to cite, some factual argument to make, let him do so. Otherwise, sewing doubt for the fun of it informs and helps no one.
Copy link to clipboard
Copied
Tom Hogarty - Perhaps you could add some comments to the murkiness of 'the cache sizes for optimal performance'?
After all, you are the Program Manager, and you did initiate this thread.
Best Regards
Phil
Copy link to clipboard
Copied
Tom's on paternity leave at the moment. I've asked someone from the Lightroom engineering team to chime in.
Copy link to clipboard
Copied
Jeffrey Tranberry wrote:
Tom's on paternity leave at the moment. I've asked someone from the Lightroom engineering team to chime in.
Jeffrey,
Thanks for the response, I wish Tom and his family well as I'm sure all Lightroom users do
Just for information, this has just happened:-
I also noticed this :-
I have upgraded to LR3.3, so why it is showing LR3.2-20100903 in the title bar I have no idea....
As for the original error, I simply selected the photo from the filmstrip while in develop module, and the error box flipped open. It is a NEF file from a Nikon D90.
Hope some of this helps.
Phil
Copy link to clipboard
Copied
The bottom one is the name of the catalog
Copy link to clipboard
Copied
Seán McCormack wrote:
The bottom one is the name of the catalog
Acknowledged - Thanks, Just the top one to sort out now then
Phil
Copy link to clipboard
Copied
Lightroom has stopped responding so Windows is generating a crash report. No ideas why, but that's what's being shown there.
Copy link to clipboard
Copied
thewhitedog wrote:
We can only trust that TK2142 remembers his sources' comments correctly, since he gives us no way to verify his information.
- I could go and dig up the post where a community professional (I think it was Ian Lyons) explained the ACR cache to contain demosaiced versions of the RAW files only. But to what avail? Would you believe that person more than another community professional?
- I gave you a way to verify the information. Just try for yourself. You'll see that the rendering time is dominated by the number of edits done to an image (in particular local adjustments), not by the presence or absence of a cached pre-rendering version of the image in the ACR cache.
FYI, you might find this blog entry about the role of the ACR cache useful. The text was informed by input from Eric Chan (one of the authors of the relevant code within LR). I hope this helps.
thewhitedog wrote:
So it would appear that his use of the term ACR Cache is, at best, imprecise and, at worst, misleading.
?
Please note that you use "Camera RAW" and I used the abbreviation for "Adobe Camera RAW". That's not a big difference to me, in particular given the fact that LR is basically just a fancy GUI to SQLlite and ACR. ACR is not a plugin to LR and there might be some code changes but effectively, you basically got ACR under LR's hood. That makes it perfectly reasonable to refer to the Develop module cache as the ACR cache.
thewhitedog wrote:
The biggest problem with his demystifying, though, is that he uses straw man arguments to make himself look good.
?
My post was intended to debunk the notion that the size of the ACR cache is of any particular significance for getting performance out of LR. In an earlier post you wrote "The size of the RAW cache may be one of the most significant, for instance." This is incorrect. The aim of my post was to point this out, in other words to help. If you construe my attempt to be helpful as an attempt to make myself look good (how so, BTW?) then perhaps you should ignore my posts.
thewhitedog wrote:
Perhaps I should have left TK2142's remarks alone (and I'll no doubt hear from you all if that's so), but they muddied things up so dramatically that, in my opinion, at the risk of some contention, they should not be allowed to go unchallenged.
"Muddied up"? I gave you a four bullet list summary about the cache and a way to verify my statements.
Perhaps you shouldn't be looking for the fault at others.
Copy link to clipboard
Copied
thewhitedog wrote:
Some additional clarity on these issues may help those with performance problems resolve their issues. That is my hope, anyway. The size of the RAW cache may be one of the most significant, for instance.
I hope my avove post makes it clear that the size of the ACR Cache is rather insignificant (unless you are looking for a slight speed up in the Develop module for images without edits).
