Usually one should look after the app performance in parallel with app development. And that is because performance can't be (easily) added afterwards.
Let say, you have a sorted list of integers. And you need to process them using binarySearch.
In the next version of the app, there is a new requirement to process the subset of items. The straightforward way is to make a copy of items, take the required subset of items and process the copy as before.
assert(itemsCopy == subset)
This solution is composable, in the sense, that you build it using existent components (binarySearch). But it may not be quick enough. A performant way is to create a flavor of binary search, which can operate on a subset of given items.
The new requirement of processing the subset of items leads to deep changes in the former code. The composability is gone.
You may read how Walter Bright value the composability here.