[matvore]

If the fan was turning on where it wasn't before, it seems like cooling was once happening through natural dissipation, but after your fix it needed fans to cool faster. So the fix saved time but burnt extra electricity (and the peacefulness of a quiet room.)

This is pretty easy to understand IMO. About 70% of the time I hear machine's fans speed up I silently wish the processing would have just been slower. This is especially true for very short bursts of activity.

[AlotOfReading]

Obviously the proper solution is to adjust your system thermal management / power targets, but you can force programs to slow down yourself by changing the scheduling policy:

    chrt -i 0 <cmd>

[matvore]

  > Obviously the proper solution is to adjust your system thermal management / power targets,

My point is that I understand the users' complaint and request for a revert, not that I can't address this for my own machines. The proper solution for non-technical people is to ask the expert to fix it, which may include undoing the change if they were never interested in the process finishing faster anyway.

I did solve this problem once upon a time by running the process in a cgroup with limited CPU, though I later rewrote my dwm config and lost the command, without caring enough to maintain the fix.

[AlotOfReading]

    The proper solution for non-technical people is to ask the expert to fix it

This isn't something the developer has any meaningful control over. Scheduling policy is the responsibility of the host system, running faster usually consumes less power, and the developer has no way to know when an operation will kick in the undesirable fans because it depends on what else the system is running. The best they can do is a checkbox that runs the old code or adding sleep calls instead