To bufcompose or not bufcompose

Something that has struck me, across many of the patches I’ve made (recent, old) is that one can often use most of the objects internal @deststartframe and @numframes to “skip” a fluid.bufcompose~ step.

When I was working out the ‘onset descriptors’ stuff, I went really overboard in terms of optimizing to avoid using fluid.bufcompose~ altogether, thinking that was (partially) responsible for the much slower performance I was getting. (The new amazing @blocking mode changes this!)

But in more recent patches, I’ve gone more verbose/linear with it, with clearer “steps” to the process, which is easier to follow and read, but perhaps at the cost of a small amount of computation.

So I’m wondering how people have been handling this?

I suppose it can end up like other code optimization stuff, where at some point you begin to sacrifice legibility for efficiency so it’s likely a balance between the two. Also not sure how “expensive” fluid.bufcompose~ is, other than potentially spiking the scheduler while it mucks about in buffer land.

My inclination would be to privilege clarity, but for your stuff where you’re really trying to minimise any delay, I appreciate this can be tricky. FWIW, bufcomposing really isn’t going to affect your CPU too much: copying is cheap and scales pretty predictably.

1 Like

In the main patch I’m working on, the “writing” is separate from the “reading”, so even if there’s a bit of delay I’m not fussed. So yeah, here I’m going with clarity (for my sake!) on what’s happening, step by step.

1 Like