Quoting Hans-Christoph Steiner hans@eds.org:
Its not necessarily slower, since it doesn't change the CPU. This just
allows you to use the -realtime flag, which gives Pd elevated execution
priority on the CPU. This means that it is harder to interrupt Pd and
it will be allowed to use more of the CPU time. IMHO, I think this mostly affects dropouts and glitches, since Pd won't be interrupted as
often by other processes (Aqua being a likely culprit since it uses a lot of CPU and runs at an elevated priority). But its possible that it
could speed things up a little bit.
OSX schedules time slices by thread not task, which is where the problems come in to play with pd. elevating the task priority of pd won't help at bit if the gui functions still take to long to execute in the pd task and don't leave time for the audio. the best (and probably final) solution to the problem is to put the audio and gui in separate threads so they can be scheduled separately. this is the _only_ way to schedule time slicing with reasonable results on OSX. again, every major piece of audio software already does this which is why Logic, Pro Tools, SuperCollider, etc are not effected by GUI actions like pd.
cgc