Closed gdsa32 closed 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.
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:
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.
Closing this in favor of #285
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:
Expected behavior Only the defined number of CPU threads should be used during compression.
Screenshots![image](https://github.com/Lymphatus/caesium-image-compressor/assets/39100541/addf1bc7-c563-4240-beaa-507067ed722f)
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%.