alt Hacker NewsYes, the sample was two cold starts. The warm request benchmarks used 100 samples per route.
You raise a good point about the hardware generations. I would like to do a larger sample, though I'm not so concerned about benchmarking each cpu separately since deployers can't control the hardware their functions run on.
IMO your thought about the idle lifetime is plausible. But the distinction between how Event and Web functions handle idle time (outside of billing) is that Event functions are frozen after the invocation completes. No code can execute while frozen. Whereas Web functions stay alive during that entire period. They can do anything they want after the invocation completes and before they are shut down.
I confirmed this by logging heartbeats during the idle period.
Thanks for your thoughtful comment.
> I would like to do a larger sample, though I'm not so concerned about benchmarking each cpu separately since deployers can't control the hardware their functions run on.
Yes, if you run at least 100 coldstarts and ignore the hardware, you'll get a good real world representation. I usually execute the function every 8 minutes for a day so I get a good sample size. If you're curious to see the difference that hardware makes on coldstart times, I have a recent writeup here: https://speedrun.nobackspacecrew.com/blog/2026/10/15/shrinki...
> But the distinction between how Event and Web functions handle idle time (outside of billing) is that Event functions are frozen after the invocation completes. No code can execute while frozen. Whereas Web functions stay alive during that entire period. They can do anything they want after the invocation completes and before they are shut down.
Yes this is correct. I got the impression you weren't trying to do any extra work after the request which is why I was suggesting that event functions would be cheaper for use cases that are mostly coldstarts.