plugdata-team
Control message layer performance issues unique to plugdata?
After encountering some surprising slow performance in a patch with a lot of array access, I decided to make a simpler patch to see what is the raw speed of accessing arrays in loops.
| Pd vanilla | Plugdata | SuperCollider | |
|---|---|---|---|
| [until] only (1,000,000 times) | 4-5 ms | 5 ms | 11 ms |
| [until] with (index+1)%100 | 28 ms | 310 ms (!) | 27 ms |
| index --> [tabread] | 70 ms | 450 ms (!) | 48 ms |
Plugdata sometimes runs as long as 600 ms for this test.
(The SC test is apples-to-apples in terms of the operations written into the test code, but not in terms of the language engine -- nothing should be inferred from those results except that a million array accesses shouldn't take more than a few dozen ms.)
So there seems to be something specific to Plugdata that slows down the Pd message passing engine. Adding 2 math ops per cycle is two orders of magnitude slower; then, the array access alone is 2-3 times slower (not counting loop control) than Pd or SC's entire loop run: +150 ms non-inclusive, vs 70 or 48 ms total.
Patch (rename to .pd): million-array-accesses.txt
Interesting results.
Can you add which specific plugdata version you are testing with? There have been quite big changes between the latest stable release (0.9.1) and the latest nightly.
Just to make sure you are working with the newest builds.
I'm not sure what version you are on, but this has improved drastically in v0.9.2! Running your test isn't as fast as Pd yet, but still more than 2-4x better than before. Considering you're coming in at around 300ms too, I assume you're on v0.9.1 here?
The problem is that plugdata captures all Pd messages that are sent, both to update our GUIs, and to do things like cable debugging, object/connection glow on message, etc. This is very performant for normal amounts of messages (using a large preallocated buffer), but if you send a million all at once, there is no way around the fact that we need to allocate a large buffer of memory to store those messages at some point, which introduces a big performance hit.
If you actually disable "Debug" in the overlays menu you'll get another ±25% improvement:
I'm not sure what version you are on, but this has improved drastically in v0.9.2! Running your test isn't as fast as Pd yet, but still more than 2-4x better than before. Considering you're coming in at around 300ms too, I assume you're on v0.9.1 here?
Hm, according to the About window, I'm on 0.9.2. I also tried the current nightly just now -- no significant improvement, except for disabling debugging.
So the gains don't translate to all systems.
So the gains don't translate to all systems.
Can you give more details about your system, then?
OS, standalone/plugin, etc.
I'm not sure what version you are on, but this has improved drastically in v0.9.2! Running your test isn't as fast as Pd yet, but still more than 2-4x better than before. Considering you're coming in at around 300ms too, I assume you're on v0.9.1 here?
Hm, according to the About window, I'm on 0.9.2. I also tried the current nightly just now -- no significant improvement, except for disabling debugging.
So the gains don't translate to all systems.
I think it's more likely that this is the improved state, and that it was even worse on v0.9.1 :(
Though indeed it also seems related to the machine the user works on, probably memory speed is a big factor here:
Since it needs to log messages from the past to memory, that can become a bottleneck if you send millions of messages at once. The difference isn't as big on my MBP, probably because it has an SoC with very fast memory. I can try to improve on this still though