P: Make use of extra cores to process multiple photos in parallel

Dunno what to say: I think Lr has been "CPU allocation challenged" since day one. I also have apps that can utilize all cores at 100% (for extended periods of time) when doing cpu intensive computation - dunno why Lr can't too, or doesn't. I get better CPU allocation than some, but even on my machine the average CPU consumption during a multi-second export is way under 100% (not sure exact number...). I would expect that to be primarily CPU bound, and hence very close to 100% most of the time. Maybe I don't understand the nuances/details, or maybe Adobe really hasn't programmed Lr "correctly" - just dunno... If down-throttling for UI responsiveness is the rationale, then something is not being done optimally, or so I speculate from the comfort of my padded armchair...

Hmm.. Im using 4.3RC. Don't see improvement there.

I agree - If Adobe has down-throttled export CPU usage so UI remains responsive, they really need to optimize... - that would *not* be considered "best practice", programming-wise.

On the other hand, you may find Lr4.3RC1 is better in this regard. In previous versions anyway, parallel exports greatly increase export throughput on some systems, but on others: not so much. - They fixed some processor utilization issues in .3 candidate.

Here's what Adobe should do---> Take a look at Final Cut X and how they tackle real-time rendering.

If Adobe says that they bind the CPU load for exports to keep some overhead CPU for running the UI, I say they simply look at what's going on in the interface. If the mouse is idle, boost the CPU usage to execute export (or other job) as fast as possible. But, as soon as I start moving in the module, clicking on photos and doing other tasks within LR, scale the CPU back on that export. Final Cut X has a user-set timeout period before the CPU kicks into rendering mode. Same could apply to LR. Get up from the computer and 5 seconds after no action, LR floors the CPU.

It's patently silly that we have to divide up our exports into 3 groups to get the software to use 100% of my cpu power. As a pro, when I export, 99% of the time I want it now. I'm not moving onto other jobs. This has been an issue since the beginning.

[If I were wanting to move onto other jobs, I'd want to have some sort of job queue to run at midnight, but that's for another thread.]

Definitely agree, resource allocation should be a task of OS but not Lightroom itself. It should use all resource available to speed up its processing.

John, this really opened a new idea! Thanks! I will look at the SDK and see what can be done there..

I think it's best to use all available horse power, and let process priority dictate how it gets shared among apps. Apps shouldn't have to artificially restrict CPU usage - that's what the OS/priority system is for. On my machine, all cores are sometimes utilized at 100% during export, just not for as much of the time as I would expect (goes up to 100% for a while, which is good, then drops down, for longer than I would expect, which is bad, then back up...). I run Lightroom at below-normal priority - long exports have no noticeable impact on other normal priority apps (I started doing that so I could watch HD video without any stuttering, while exporting...). With Lightroom at normal priority, there is occasional stuttering during HD video playback... Other apps doing CPU-intensive tasks (e.g. video/audio compression, use CPU at 100% almost the whole time, without interfering with other higher priority apps (same priority app performance may be degraded, lower priority app performance will get no cpu while higher priority apps are contending for it).

It's long been a mystery what Lightroom is doing sometimes - CPU not maxed out, but ultra-fast disks don't help much - hmmm.... what's the bottle-neck then?

It could be that Lightroom's got some serious problems in the multi-tasking department which is accounting for some of it's ongoing performance woes - even when functioning normally.

If Lightroom is truly so "memory-bound" (I'm not convinced yet), I'd really like to understand that better...

I don't believe so, Bob, since there's no SDK access to previews. You can see what I did with exports here.

Hi John, Can you do the same for preview rendering?

Bob frost

Coincidentally, today I was playing with controlling an export through code . Breaking a 267-file export into 3 roughly-simultaneous exports saved 60% of the start-to-finish export time. I may develop it a little further - for example letting the user choose how many simultaneous batches to run - but the existing code does bypass the standard export dialog so I'm not sure it would be compatible with other plugins.