I think the thread that processes the background queue should run at “Idle” priority. That way the UI (and the rest of Windows) will still be more responsive even though the batch is being processed.
This may even make sense on other OSes too.
that might make sense in your workflow. but not in general.
Well, which workflows will benefit from a sluggish UI? Please explain.
I think he means lots of people benefit from fast queue processing.
Well, lowering the priority doesn’t lower the speed of the processing as such. That’s a common misconception. An example:
Let’s say processing the queue takes 5 seconds.
The user also wants to do stuff with the UI, and this takes 0.1 second.
All in all, that’s 5.1 seconds of work that needs to be done by the CPU.
The only thing the priority does is change the order of execution, meaning that the UI will be updated first (which makes things feel more snappy), and then it will proceed with whatever remains of the 5 seconds queue work.
Result if you did this: Everything would still take 5.1 seconds in total, but the UI would feel more responsive because the CPU cares about this first.
(Actually Linux and BSD does this automatically. And many Windows programs which do lengthy processing offer this feature as well because Windows doesn’t do this automatically.)
I also would like to suggest considering doing something with the priority of the tasks. As an example: When I Pasted in “Processing Profile Operations” the adjustments to the hundred of photos, I needed to wait several minutes before the program finished this task (by the way it was using only one processor core for that, 25% of my Quadcore processor). This simple task must be a background task, not something that freezes the workflow.
1 Like
Wouldn’t you be even more upset if you try to open a window and your change isnt applied yet?
1 Like
I dream of an os where the ui never, under any circumstances lag. Generally speaking it’s fine if background processes take longer.
1 Like