Agreed in general, but it's also the level of inefficiency that matters. In the case of jump vs call/ret and those others, you're looking at a less-than-double

Agreed in general, but it's also the level of inefficiency that matters. In the case of jump vs call/ret and those others, you're looking at a less-than-double increase in time. It's there and you can optimize it, but if you don't you don't really notice. FRP can be very different. With a large chunk of data and the wrong methods, you could be copying and re-copying that data over and over instead of editing it in place. This isn't just a 100% slowdown - you can go from 5 seconds to 500 seconds when converting an in-place data modification to FRP. Basically O(n) vs O(2n) ? Optimize it later if necessary O(n) vs O(n^3) - Uh oh! That's not to say that FRP is bad or you shouldn't use it, but never use a 'magic' mapping in FRP unless you know exactly what it is doing to the data and if it's going to copy or not (hint: it usually is).