It's from my experience. Ableton is optimised to cram as many plugins onto a single thread as possible, which means you are quickly going to run out of processing power when using more CPU demanding plugins, because as soon as you exhaust one cpu core, the project will no longer play in real time. When plugins run from their own process, the OS take care of distributing the load across multiple cores and that lets you run more plugins before it will overload.
So I agree that sandboxing is not done to gain perfomance, but better perfomance is an unintended side effect. That shows how bad Ableton scheduling is.
It shows how slow your CPU's single threaded performance is and the trade off between latency and throughout in modern computing more than anything.
My experience from actually writing low latency schedulers in user space as well as the publicly available material - like in Ardour - suggests different conclusions from yours.
Keep in mind that a naive benchmark like "cpu usage" is entirely meaningless. What you look at is round trip latency required for a threshold of underruns/missed deadlines. Threading requires additional latency, and process synchronization even more. While I'm sure you report fewer underruns when splitting off into sandboxed plugins I'm suspicious if it's hitting the same performance as doubling or tripling the buffer size in terms of latency in the first place.
I am using i9 9900k @5GHz so I think it is quite fast. The plugins I use are CPU heavy and you can run limited number of them on a single core. I am not interested in low latency - I am running 1024 buffer, however I would like my projects to play smoothly even if there is latency. Ableton unfortunately does not work well with such use case as it won't parallelise where it could and sandboxing does just that and I can run more plugins, even if it seems less efficient.
Re:Ableton Live 11
by spacechild1 on Thursday November 12, 2020 @07:19AM
(#25069014)
For other readers: It is a misconception that sandboxing per-se enables parallelism. On the contrary, it only hurts performance. The speedup observed with jBridge might have other reasons. More here: https://news.ycombinator.com/item?id=25068976
Sand boxing isn't done for performance reasons, and it's why you can disable it in bitwig. The sole purpose of sand boxing a plugin in its own process is because it is the only way to catch a segfault and prevent a shared library from crashing a host.