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

I'm running a quad core i5 with 20GB ram and a 500MB/s SSD(neither is maxe'd or even taxed), the max processor use I ever see is 300% fluctuating greatly. Seti@home runs 4 instances of itself, PEGS the processors at 400% (100 each) for days on end and still manages to gracefully allow other programs (even photoshop) to work normally like a well written background process should. Perhaps Adobe could consider making a hefty donation to Seti@home for them to optimize their photo applications for multi core processing?

BUT, this is what the program should be PROGRAMED to do for us. (sorry for yelling)

I am glad that so many people think the same as me. I hope that Adobe could consider any of the idea here

Lightroom doesn't seems to fully utilizing the CPU/memory. For example on export on my quad-core CPU, utilization often drops to 40-60%. It seems like the writing of the resulting files needs to be done asynchronously with reading/writing files



Note: This topic was created from a reply on the Lightroom: Use idle CPU in grid mode and multi-threaded utilization (performa... topic.

My typical workflow after importing is to keyword the imported photos. Even with previews pre-rendered, scrolling down in grid view is a bit painful. As I'm working away on my current screen full of thumbnails, LR could be doing whatever it needs to do to make it faster to render the thumbnails further down.

Another way to describe it would be to take better advantage of idle CPU and memory.
Better multi-threadedness would be appreciated too on imports and exports.

When converting RAW images, process one image per core. Similar to SETI@home. It may not be efficient to split the conversion of an image across multiple cores but running 4-16 conversions at a time would speed up the overall batch. I don't know if this means that ACR would need to spawn as many instances of itself as there are cores or not. Of course this is memory and disk bandwidth limited, but that can be addressed by the user.

Sean,

You're preaching to the choir: I don't see any reason why the CPU couldn't be far more utilized when rendering a single image for develop. And regardless, pre-caching (aka look-ahead caching) for develop would be a worthwhile optimization, in my (armchair) opinion.

PS - I have no idea whether the GPU could be tapped for rendering tasks - I would guess: not really.

Rob

That last bit there... since all of the dev stuff is serial [photo 1, then 2, then 3, then 4] doesn't it make sense to be CPU aware and prerender 2,3 and 4 in the same time it takes to render the current image in the dev panel? In other words, yes, I can confirm that selecting a new image uses 6 cores and 6 threads at about 25%. That means my CPU (1/2 of the threads are idle) and hella powerful GPU are sitting around while I wait as well. Seems like there's a ton of room for optimization here, but I'll admit as you, I'm mostly armchair.

Yep - I think it's high time Adobe took a good hard look at their software from a CPU allocation perspective. - you shouldn't have to stack up export jobs like that...

But since you do, consider using publish services to help facilitate simultaneous exports, or ExportManager if your exports aren't via publish services.

The same thing that keeps Lr from being as fast as possible during exports (only partial CPU utilization) is also keeping it from being as fast as possible when rendering for develop...

I have a 6-core system. With one export job, all 6 cores are in use but at 30%. When I stack up 3 export jobs, I can peg the CPU at a full 100%, all 12 threads.