Can I define CPU usage limit for an application?

Assuming your Mac can accept additional RAM, that is your best option.

An application that you desire would require going into the 'bowels' of OSX which could get very complicated. In addition. user set parameters do not mean that overall performance would be improved, rather it could be just as well the opposite.

Ciao.

No it is not simple. It really requires messing with the operating system scheduler. But nothing is simple. Video rendering uses a lot of RAM and often does a lot of DIsk I/O. So you would also need to limite RAM usage, and I/O usage if that would conflict with othe apps. But if you limit RAM, then the restricted app would start paging and swapping, which would increase I/O. And to make life more fun, the operating system runs under the processes identity to perform administrative tasks, like paging and swapping, so since you are restricting CPU usage, the process would not be able to run to do its own paging, because it was using too much CPU already.

Another approach would be to use a utility that plays with a process' 'nice' setting

<https://www.macupdate.com/app/mac/36748/processrenicer>

<https://www.macupdate.com/app/mac/9579/benicer>

This does not limit a process' use of the CPU, I/O or RAM, but it does give priority CPU access to other processes.

Too bad this wasn't thought at the initial steps on the first day a man started programming a system 😝

Oh, but they did. Well many not the very first, as in those days there was no operating system. The system ran one program, which was manually loaded before the run.

But when they did get around to writing operating systems, some of them were used to provide time-sharing for customers. And customers could pay more for better access to the CPU, and others could have a much lower bill if they purchased a lower amount of CPU. And in many of these cases, if you purchased 10% you got ONLY 10%. It did not matter if no one else was using the other 90% at 3:00am, you paid for 10% and that was all you were getting.

They also charged you by the time you took to run your job, so you may pay less, but it took you longer to run your job, so you accumulated a higher bill (just not as high a the ones that paid for 40%, as the cost per minute was more than 40% higher).

But like I said, your I/O demands also affected both your and other time-sharing user performance. Also the amount of RAM you needed to use, and if you needed to use the card reader, or the card punch, or the printer. These factors added great complexity to the scheduler and it was very difficult to get it right.

I think you can build versions of Linux with "Your Own" scheduler that may offer some of these features, but it is not used very often, and rarely improves over all Linux performance.

And once personal computers came along, the world first moved back to "My Computer" and I'm running 1 program at a time. This was partially because people were fed up with sharing, and partially because an operating system requires a lot of resources, and running them on systems with 16K bytes of RAM is difficult.

But Personal computer grew up, and got powerful operating systems, but they did not really need time-sharing era CPU, I/O, RAM limitations that are too complicated for individual users to manage in a way that actually gives the user the results they really want, are a pain to maintain for developers, generate problems for customer support, and would be rarely used anyway.

So you get process priority. have a 'renice' day :-)

You can use series of SIGSTOP and SIGCONT signals sent with reasonably calculated delays in infinite loop

e.g.

SIGSTOP

wait 90 usec

SIGCONT

wait 10 usec

You can sent signals by kill application and wait by sleep application in a shell script

do not forget to use right units of measurements.

e.g. create a file with following content and make it executable, so that it'll depress cpu consumption to 10%

swap sleep intervals and you'll have it depressed to 90%

echo "enter process id"

read pid

echo "press Ctrl-C to exit"

while true

do

kill -SIGSTOP $pid

sleep 0.009

kill -SIGCONT $pid

sleep 0.001

done

Like the other guys said, limiting the amount of RAM a specific application can use is counter-productive and risky, since it would interfere with the RAM usage limitations the devs set in their code. Any number lower than their minimum could make the application unusable, or unstable at best.

There's also the question of limiting RAM usage, and allowing the application to write to disk instead, since it would slow everything down. Not a good option.

However, I've found this nifty little app called ATmonitor, that will let you renice processes (which means limiting the CPU usage allowed to any given application), and make the new setting stick between reboots, provided you let ATmonitor run on startup.

Problem is, it doesn't start as hidden, and the icon will show in your Dock on every startup, and stay there.

You can use another app like Dock Dodger to prevent that, and you're in business.

ATmonitor: (free - 32-bit)

Dock Dodger: (free - 32-bit)

BTW, there is simple tool AppPolice that you can use, but it shows not all the process, unfortunately(