| The biggest loser is calendar, which uses scanl. I am not fully sure | what went wrong here: Either the one-shot annotation on the lambda’s | variable got lost somewhere in the pipeline, or despite it being there, | the normal arity analysis did not use it. | | But there is also a winner, fft2, with -1.5% allocations. Here Call | Arity was not good enough, but oneShot did the jobs. It's always useful to discover what happens. Why didn't Call Arity do the job? How did the one-shot-ness get lost? I know it takes work to find out these things; but sometimes they show up something that is easy to fix, and which gives improvements across the board. | best keep the oneShot annotation in the unfoldings: The isOneShotLambda | flag is currently not stored in the interface. I work around this by | making sure that the oneShot function is never inlined in unfoldings, | but maybe it would be better to serialize the isOneShotLambda flag in | interfaces, which might have other good effects? Serialising the one-shot lambda info sounds like a good plan to me. | If we want as much performance as possible, we should simply include | both approaches. But there might be other things to consider... so not | sure what the best thing to do is. I'd be inclined to do both. Call-arity hits programs where the programmer had no idea that there was something to do; or where the lambda isn't *statically* one-shot... it only becomes so when inlined into a particular context. One-shot-lambdas may help in situations where the one-shot-ness is manifestly too hard to spot. Good work! Keep a wiki page to describe the choices, point to the tickets, etc Simon