LrC backup function

[bakubo]

Everyday I use the LrC backup function to check the integrity, optimize, and create a compressed backup of my catalog. Something that has always seemed strange to me is that on my M2 Pro 12/19 which has 4E and 8P CPU cores it looks like LrC is only using the 4E cores to do all the work. My compressed catalog is 2.03gb, uncompressed is 2.2gb.

My 8P cores are barely used when I use LrC. The backup function seems to do a lot of work, but just uses the 4E cores.

Anyone else noticed this?

 

[graybalanced]

My 8P cores are barely used when I use LrC. The backup function seems to do a lot of work, but just uses the 4E cores.

Anyone else noticed this?

Hadn't noticed it, only because I haven't looked at Activity Monitor during an LRC backup. At first glance it seems strange, but after a little reflection it does not seem so strange after all.

The reason it seems less strange is that is exactly what Apple Time Machine does. A Time Machine backup practically never saturates processors or data throughput to the backup device. Why is that, it's because backup is categorized as a low priority performance task. Nobody wants their high performance task to slow down because a backup is running in the background.

In the past this would be achieved by restricting how much of the Cpu that a backup can take over. With current processor architectures, it is now standard across Mac OS that utility tasks like backup are shunted to the efficiency cores so that the performance cores are left free and available for high priority foreground tasks. This is not a big a penalty as it might seem because especially with the later M series Apple Silicon, efficiency cores are now able to achieve a percentage of performance core speed that is disproportionally high relative to their much lower power level. And because nobody wanted the backup software to max out the machine anyway, there is no widespread call to have backup software max out even the efficiency cores.

I know LRC backup is different in nature from Time Machine because the LR backup is not a background task. A slower LRC backup means you wait longer for the whole application to shut down, which is a major pain in the rear when you just want it to quit already. But they might have designed it like other backup apps (low priority, efficiency cores) even though in LR it might be better to give it all the gas to get it over with sooner and finish quitting the app.

 

[Zeee]

This is not me. I found this on another site. May help or not.

This is the purpose of the "Optimize Catalog process". A database stores records and deleting the record does not release the space taken up by that record. There is a database command called "VACUUM" that rewrites the database into a compact form. The "Optimize Catalog" closes the data base file to other writes and issues this command.

 

[bakubo]

Everyday I use the LrC backup function to check the integrity, optimize, and create a compressed backup of my catalog. Something that has always seemed strange to me is that on my M2 Pro 12/19 which has 4E and 8P CPU cores it looks like LrC is only using the 4E cores to do all the work. My compressed catalog is 2.03gb, uncompressed is 2.2gb.

My 8P cores are barely used when I use LrC. The backup function seems to do a lot of work, but just uses the 4E cores.

Anyone else noticed this?

I just saw this new video comparing the M5 to the M4 Pro using LrC. I have it cued up to 15:45:

He exports 50 42mp photos and then he exports 500 42mp photos. He notices that on both computers LrC has all the E cores at 100%, but it is only lightly using the P cores.

It seems that Adobe is not making good use of Apple hardware and is slower than it could be.

 

[paulraphael]

It makes sense. Developers assign a "quality of service" rank to every thread they spin off from an application's main thread. These range from "user interactive," for tasks that require real-time feedback from the user interface and so are most performance-sensitive, to "background," for tasks that happen ... in the background. Presumably these are tasks that no one's waiting for, including backup tasks.

MacOS automatically restricts background tasks to the e-cores, both to save energy, and to keep the p-cores available for user tasks that demand performance. Conversely, higher quality-of-service tasks, if they're able to scale to many processors, might temporarily bump processes from the e-cores. So you'll occasionally see a user task taking over all your cores.

 

[graybalanced]

It seems that Adobe is not making good use of Apple hardware and is slower than it could be.

I don't mean this personally towards you, more as a general observation of a misperception that is all too common:

That quote is a gross misinterpretation of what is happening, and should never have been upvoted.

You can make Lightroom use almost 100% of the performance cores on export, if you want. But it's a horrible mistake to do so which is why this is not recommended. If you want to try this, and you should, go into the LR performance prefs and shut off GPU acceleration for export.

If you do that, you will see two things: You get your near-100% performance core utilization, and........your export takes a lot longer. I just tried a large bulk export both ways, and by making LRC use high CPU performance core utilization, the export took around twice as long. So if that's what you really want, go ahead and force full CPU utilization.

Also, I noticed that my Mac ran cooler when the processing was on the GPU instead of the CPU.

What a good Mac application does, regardless of developer, is this: Which hardware on board the Mac can accelerate this the most? Is it more CPU cores? Is it the GPU? How about the Neural Engine? Or maybe the Media Engine? Any time an application is able to be coded for a hardware accelerator instead of a CPU, it is preferable to use that hardware instead of the CPU!

Video editing applications for example, can make great use of the GPU and Media Engine, and that is why high definition video editing can be surprisingly doable on a MacBook Air with its weak CPU. If you make the performance CPU cores try to do that without the GPU & ME, it will run as slow as on my old G3 PowerBook that only had a CPU, no hardware accelerators. Same with modern 3D apps: Make the CPU do everything, and it will feel like death by slow torture.

When you allow video and 3D apps to use the GPU and if your GPU has sufficient specs, it will be so much more efficient than the CPU that there may not be many tasks that are worth handing to the CPU. The CPU performance core utilization drops AS EXPECTED. This is all you're seeing in LRC, perfectly normal. The efficiency cores may continue to be busy, because on Mac OS the efficiency cores handle all other non-critical processes also running; they may or may not have anything to do with the LR export in progress.

This might also explain why Apple elevates the Max and Ultra the way they do: You pay a lot more money but you hardly get any more CPU cores. What you get is lots more GPU cores and a second Media Engine. Apple knows that is where the real high performance gains are in modern apps......not in the performance cores.