Pages: 1 2 3 [4]   Go Down

Author Topic: Lightroom performance improvements...  (Read 6615 times)

Rhossydd

  • Sr. Member
  • ****
  • Online Online
  • Posts: 2590
    • http://www.paulholman.com
Re: Lightroom performance improvements...
« Reply #60 on: August 03, 2017, 04:23:12 PM »

Because not everyone has problems?
... I see nothing like it on my system
Same here.
The only thing that responds slowly on my system when in develop is the colour temperature controls.

Spotting ceased to be an issue anyway when I got a DSLR with a self cleaning sensor ...... 7 years ago now.

Logged

john beardsworth

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 4027
    • http://www.beardsworth.co.uk
Re: Lightroom performance improvements...
« Reply #61 on: August 03, 2017, 04:37:53 PM »

Anyway, the next time it happens I'll try your suggestion to delete some of the history states as a workaround until Adobe fixes the underlying problem.

The history deletion is not a standard fix, Ron. This client has a big catalogue, 650k+ images, growing 2-3000 a week, and with 10 years of edits. The recent slowdown was very strange and I'd tried all sorts of things before I remembered hearing of a corrupt history table - so we rolled that dice. In Develop we selected all the images, then ran the Develop > Clear History menu command and eventually (30 minutes later) restarted LR. The catalogue shrank to 8gb from its previous 17gb and performance was back to normal. So it's an abnormal fix. It does though point to an opportunity for Adobe - people don't need history accumulating forever, and milestones like "Printed on YYMMDD" might be preserved while removing individual steps after a few days or weeks.
Logged
www.beardsworth.co.uk   www.lightroomsolutions.com
New Fuji-to-Lightroom plugin X-LR
Ignoring: AlterEgo, ButchM, deejjjaaaa, scyth

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 10103
    • http://www.markdsegal.com
Re: Lightroom performance improvements...
« Reply #62 on: August 03, 2017, 04:53:50 PM »

The history deletion is not a standard fix, Ron. This client has a big catalogue, 650k+ images, growing 2-3000 a week, and with 10 years of edits. The recent slowdown was very strange and I'd tried all sorts of things before I remembered hearing of a corrupt history table - so we rolled that dice. In Develop we selected all the images, then ran the Develop > Clear History menu command and eventually (30 minutes later) restarted LR. The catalogue shrank to 8gb from its previous 17gb and performance was back to normal. So it's an abnormal fix. It does though point to an opportunity for Adobe - people don't need history accumulating forever, and milestones like "Printed on YYMMDD" might be preserved while removing individual steps after a few days or weeks.

Indefinite retention of those history steps is a great feature of Lr that comes in very handy when re-working photos to suit different purposes or interpretations, so I would like to always have the option of retaining them or deleting them, perhaps on a per photo or batch basis.
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml

Rhossydd

  • Sr. Member
  • ****
  • Online Online
  • Posts: 2590
    • http://www.paulholman.com
Re: Lightroom performance improvements...
« Reply #63 on: August 03, 2017, 05:02:43 PM »

Indefinite retention of those history steps is a great feature of Lr
+1
It sounds what would be a better addition is a function or utility to check and repair the part of the database that holds the history steps.

milestones like "Printed on YYMMDD" might be preserved
OTOH this isn't a 'milestone' for me at all, or any other export function either. I'd like the option to switch off logging this sort of unimportant clutter.
Logged

john beardsworth

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 4027
    • http://www.beardsworth.co.uk
Re: Lightroom performance improvements...
« Reply #64 on: August 03, 2017, 05:25:35 PM »

It's far from unimportant clutter because it's essential if you ever want to go back and rework that print or supply an exact copy of a file, but these milestones and the entire History panel's value is limited by not being searchable. Imagine if you could filter on which images you've not exported, or find images with ISO>1000 and no NR step. But I've given up on Adobe ever providing that searchability and would be quite content with automated History culling if it's part of tuning performance.
Logged
www.beardsworth.co.uk   www.lightroomsolutions.com
New Fuji-to-Lightroom plugin X-LR
Ignoring: AlterEgo, ButchM, deejjjaaaa, scyth

Hoggy

  • Full Member
  • ***
  • Offline Offline
  • Posts: 142
Re: Lightroom performance improvements...
« Reply #65 on: August 03, 2017, 07:08:59 PM »

I have experienced lagging when doing lots of brushwork on my new 27" iMac with an AMD Radeon Pro 580 with 8GB of VRAM.  That's not specifically listed by Adobe as supported/tested although it far exceeds their minimal requirements.  https://helpx.adobe.com/lightroom/kb/lightroom-gpu-faq.html 

Anyway, the next time it happens I'll try your suggestion to delete some of the history states as a workaround until Adobe fixes the underlying problem.
Since you notice this too, and in case you hadn't heard, and because you started this thread..  ;)
The slew of workarounds to reduce or eliminate the lag when making brush strokes can be a combination of things to try.  Turn off GPU acceleration, turn off any crop rotation, turn off lens profile corrections including distortion from the manual tab - in the transform panel, turn off upright and turn off any manual transforms.
Whew!  Am I forgetting anything?   :o   Some of these things may be so ingrained that people may have already incorporated the workarounds into their workflow, and not notice them anymore.
...........
As far as the history steps go, I find that after any amount of time the steps don't mean anything to me anyways..  And they tend to really bloat the catalog size as each step seems to be an internal snapshot.  What I do instead, is to use snapshots - in which I can put much more useful information in there than a slew of absolute steps taken.  Like what was done, and/or what I was trying to accomplish, and/or what I still need to do.  Whenever I might export/share, I use JF's Snapshot-on-Export/share facilities to 'set it in stone' - unfortunately for those that print, there is nothing similar for printing other than doing it manually.  (EDIT: And as implied, about 99% of the time, I'll then clear the history panel after making the snapshot.)
« Last Edit: August 03, 2017, 11:08:37 PM by Hoggy »
Logged
Cams: Pentax K-3, K-30 & Canon G7X, S100
Firm supporter of DNG, throwing away originals.
It's the hash, man..  That good hash!

rdonson

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2538
Re: Lightroom performance improvements...
« Reply #66 on: August 03, 2017, 08:22:50 PM »

Whew!  Am I forgetting anything?   :o   Some of these things may be so ingrained that people may have already incorporated the workarounds into their workflow, and not notice them anymore.

I didn't miss anything.  The workarounds are noted and are NOT a substitute for Adobe addressing the issue(s).
Logged
Regards,
Ron

Rhossydd

  • Sr. Member
  • ****
  • Online Online
  • Posts: 2590
    • http://www.paulholman.com
Re: Lightroom performance improvements...
« Reply #67 on: August 04, 2017, 01:22:26 AM »

It's far from unimportant clutter
To you maybe.

But that was your point. What's important to one user is clutter to another. Which is why getting development of the product suiting everyone is so difficult.
Logged

john beardsworth

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 4027
    • http://www.beardsworth.co.uk
Re: Lightroom performance improvements...
« Reply #68 on: August 04, 2017, 02:49:15 AM »

What's important to one user is clutter to another.

Which is why any performance benefit from wiping History needs to preserve the milestones. It's a balance of needs.
Logged
www.beardsworth.co.uk   www.lightroomsolutions.com
New Fuji-to-Lightroom plugin X-LR
Ignoring: AlterEgo, ButchM, deejjjaaaa, scyth

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 10103
    • http://www.markdsegal.com
Re: Lightroom performance improvements...
« Reply #69 on: August 04, 2017, 08:28:09 AM »

To you maybe.

.................... getting development of the product suiting everyone is so difficult.

Sure, but one effective way to mitigate this circumstance is to provide for options in Preferences. I'm not a programmer, nor do I know much about how operating systems process instructions, nonetheless it seems reasonable in a case like this to surmise that a user-selected preference could be structured within Lr to either maintain or scrap history steps in batches of photos and that when the "scrap" option is selected, history steps would be treated say, like they are in Photoshop. But all this presumes history steps do cause the application to slow down. Do we have any real evidence of this being the case? Or is it circumstantial evidence based on correlation of variables that may not be correlated under the hood?
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml

john beardsworth

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 4027
    • http://www.beardsworth.co.uk
Re: Lightroom performance improvements...
« Reply #70 on: August 04, 2017, 09:34:45 AM »

But all this presumes history steps do cause the application to slow down. Do we have any real evidence of this being the case? Or is it circumstantial evidence based on correlation of variables that may not be correlated under the hood?

I provided one when I introduced the topic, though I do not think there is any general evidence that a large accumulation of history steps does impact on performance. Adobe will probably be looking for general and specific/exceptional performance issues.
Logged
www.beardsworth.co.uk   www.lightroomsolutions.com
New Fuji-to-Lightroom plugin X-LR
Ignoring: AlterEgo, ButchM, deejjjaaaa, scyth

MBehrens

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 265
Re: Lightroom performance improvements...
« Reply #71 on: August 08, 2017, 09:40:33 PM »

The most infuriating slow feature of LR, well maybe not the most, but it bugs me every time I start the app. The slowness with which the image counts are displayed in the Folders panel of the Library module. What is going on here? The number of files has not changed since I shut down. It isn't going to change the number if I have added files to the OS folders while it was shut down. And even if I have disconnected the library it will still display the last number of files that it knew about. This isn't a complicated DB query, and the query would not return them on a folder by folder basis, it would return the entire set and it could simply be displayed.

Sure, yeah, I know, I don't have to wait for the counts, I can select a folder and go on my merry way. It is contributing to the feel of the application. And the feel is lethargic in general

I suppose that there needs to be some reconciliation of the Catalog files to the OS Files, but does every folder need to be reconciled on startup? If I access 5% of the folders in a session it is a lot. Typically I'm working in 1 or 2. The other 100s are reconciled for naught. Maybe I simply need to have my entire computing storage space as SSDs, then this might happen in a snap... somehow I doubt it.

Are other folks experiencing this oozing of folder file counts on startup? Maybe it is just me.
Logged

rdonson

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2538
Re: Lightroom performance improvements...
« Reply #72 on: August 09, 2017, 10:49:31 AM »

It's not just you.  I have the latest 27" iMac with the fastest processor and 40GB RAM and I see it.  My images are stored on a Drobo 5Dt connected via Thunderbolt 2.  Definitely faster than my old iMac but it's certainly not as fast as I think it should be.
Logged
Regards,
Ron

Rendezvous

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 78
    • Daniel Talbot Photo Blog
Re: Lightroom performance improvements...
« Reply #73 on: August 20, 2017, 07:06:58 PM »

The most infuriating slow feature of LR, well maybe not the most, but it bugs me every time I start the app. The slowness with which the image counts are displayed in the Folders panel of the Library module. What is going on here? The number of files has not changed since I shut down. It isn't going to change the number if I have added files to the OS folders while it was shut down. And even if I have disconnected the library it will still display the last number of files that it knew about. This isn't a complicated DB query, and the query would not return them on a folder by folder basis, it would return the entire set and it could simply be displayed.

Sure, yeah, I know, I don't have to wait for the counts, I can select a folder and go on my merry way. It is contributing to the feel of the application. And the feel is lethargic in general

I suppose that there needs to be some reconciliation of the Catalog files to the OS Files, but does every folder need to be reconciled on startup? If I access 5% of the folders in a session it is a lot. Typically I'm working in 1 or 2. The other 100s are reconciled for naught. Maybe I simply need to have my entire computing storage space as SSDs, then this might happen in a snap... somehow I doubt it.

Are other folks experiencing this oozing of folder file counts on startup? Maybe it is just me.

Yes, I know how frustrating that is! I found that the startup portion became significantly faster when I changed my iMac from a standard hard drive to a solid state. This is with the catalog and preview files on the hard drive. The original images are on an external. Originally my iMac was taking a good couple of minutes before LR was in a useable state with all the numbers populated and the previews shown, now it is around 20 seconds. For reference, my catalog file is approximately 3.5GB.
Pages: 1 2 3 [4]   Go Up