# To bufcompose or not bufcompose

**URL:** <https://discourse.flucoma.org/t/to-bufcompose-or-not-bufcompose/337>\
**Category:** Usage Questions\
**Created:** [October 30, 2019, 9:57am UTC](https://discourse.flucoma.org/t/to-bufcompose-or-not-bufcompose/337 "2019-10-30T09:57:56Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![rodrigo.constanzo](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/rodrigo.constanzo/32/12_2.png) [@rodrigo.constanzo](https://discourse.flucoma.org/u/rodrigo.constanzo)\
**Post date:** [October 30, 2019, 9:57am UTC](https://discourse.flucoma.org/t/to-bufcompose-or-not-bufcompose/337/1 "2019-10-30T09:57:56Z")

</div>

Something that has struck me, across many of the patches I’ve made ([recent](https://discourse.flucoma.org/t/wrap-attribute-for-fluid-bufcompose-or-suggestions/336), [old](https://discourse.flucoma.org/t/musical-use-of-descriptors-discussion/76)) 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.

---

<div class="post-metadata">

**Author:** ![weefuzzy](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/weefuzzy/32/362_2.png) [@weefuzzy](https://discourse.flucoma.org/u/weefuzzy)\
**Post date:** [October 30, 2019, 6:13pm UTC](https://discourse.flucoma.org/t/to-bufcompose-or-not-bufcompose/337/2 "2019-10-30T18:13:55Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![rodrigo.constanzo](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/rodrigo.constanzo/32/12_2.png) [@rodrigo.constanzo](https://discourse.flucoma.org/u/rodrigo.constanzo)\
**Post date:** [October 30, 2019, 7:23pm UTC](https://discourse.flucoma.org/t/to-bufcompose-or-not-bufcompose/337/3 "2019-10-30T19:23:25Z")

</div>

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.