Lymphatus / caesium-image-compressor

Caesium is an image compression software that helps you store, send and share digital pictures, supporting JPG, PNG, WebP and TIFF formats. You can quickly reduce the file size (and resolution, if you want) by preserving the overall quality of the image.
https://saerasoft.com/caesium
GNU General Public License v3.0
3.31k stars 202 forks source link

Caesium always uses all available CPU threads, even when told not to #284

Closed gdsa32 closed 3 weeks ago

gdsa32 commented 3 weeks ago

Describe the bug When processing a large batch of images, Caesium always uses all CPU threads available, even if we configure it to use only part of them. This causes the entire system to be irresponsive, even with a powerful CPU.

Software version v2.7.1

Operating System information

To Reproduce Steps to reproduce the behavior:

  1. Open the Windows Task Manage and go to 'Performance > CPU'.
  2. Click on the graph e choose 'Change graph to > Logic processors'.
  3. Notice how the current running processes are using the CPU threads.
  4. Open Caesium, go to 'Preferences' and change the Multithreading field to a value that is smaller than the total count of CPU threads in your system. In my case, I reduced from 16 to 12 threads.
  5. Close the Preferences window.
  6. Load a large batch of images in Caesium (say, 200 or more large images) and set a desired value for quality.
  7. Make sure both Caesium and Task Manager are visible on your screen. Then click compress e observe the CPU use on the Task Manager. You'll notice all threads have 100% utilization, even if you configure it otherwise.

Expected behavior Only the defined number of CPU threads should be used during compression.

Screenshots image

image

Application Log caesium-2024-06-24.log

Edit I added issue #285, asking for a new setting, allowing user defined priority for the Caesium process. This way, with process priority defined to 'below normal', for example, system will albeys be responsive, even when all CPU threads are used at 100%.

Lymphatus commented 3 weeks ago

I tested on my Windows 11 machine and seems to work as intended. There's a catch that maybe is what you are seeing: Caesium uses a pool of threads for processing the images, and when you set the number of threads, you tell how bit the pool is. This does not define which processors/threads are used in advance, but when it start processing a new image, chooses an available thread. If you define a number close to the max limit, by switching to different threads, it might seem that it's using every of them. Could you try with a lower value, like 4 out of 16 threads to see if gets better? For me the difference was really noticeable.

gdsa32 commented 3 weeks ago

I tested on my Windows 11 machine and seems to work as intended. There's a catch that maybe is what you are seeing: Caesium uses a pool of threads for processing the images, and when you set the number of threads, you tell how bit the pool is. This does not define which processors/threads are used in advance, but when it start processing a new image, chooses an available thread. If you define a number close to the max limit, by switching to different threads, it might seem that it's using every of them. Could you try with a lower value, like 4 out of 16 threads to see if gets better? For me the difference was really noticeable.

OK. I think I understand what you said.

This is the CPU graph when I limit threads to 4: image

As you can see in the image, CPU threads do not look at 100% all the time and system responsiveness is a lot better. But obviously, processing time is much longer.

So, I think the best approach here is implementing feature request #285, allowing a user defined process priority (I certainly will use 'below normal'). This way, Caesium can use all de processing power available, without negatively affecting system responsiveness.

Lymphatus commented 3 weeks ago

Closing this in favor of #285