The big thing that makes it more efficient is that the only real guarantee is that your function will execute _sometime_ in the future. Now, those members of o

The big thing that makes it more efficient is that the only real guarantee is that your function will execute _sometime_ in the future. Now, those members of our fair technological coven, of a certain age (who are sadly dwindling in number) will certainly recognise sending off a program to be run by a big magic massive machine, and waiting for results later on. Thats batch computing. Now the key advantage of batch computing here, as also laid out by the paper is that you can group stuff together to cut out VM warmup time. BUT it also means that because you have the luxury of waiting, you can use spare CPU cycles when they are free. As with everything big sites have burst of traffic, so to handle that, you have lots of spare CPU cycles waiting around. if you clearly telegraph that your function is liable to be delayed, killed or re-run, then there are still lots of useful work that can be done without costing you more in capacity. Its a strongly under utilised pattern in modern computing.