3 ms·
It has always had much slower cold start times than other choices: https://mikhail.io/serverless/coldstarts/aws/ https://mikhail.io/serverless/coldstarts/aws/
by tyingq 5y ago
It has always had much slower cold start times than other choices:
https://mikhail.io/serverless/coldstarts/aws/ https://mikhail.io/serverless/coldstarts/aws/
- scarface74 5y agoRead the comments. He did something wrong.
- ripley12 5y agoI'm curious why that is. I've spent a bit of time benchmarking startup for plain old executables, and .NET does OK there (even without AOT compilation). Not sure what would make it slower than other languages on Lambda. https://twitter.com/reillywood/status/1459332721205936128 https://twitter.com/reillywood/status/1459332721205936128
- tyingq 5y agoThere's this post: https://blog.thundra.io/solving-dotnet-lambda-cold-start-part-1 https://blog.thundra.io/solving-dotnet-lambda-cold-start-par... It suggests a few things, including: "one of the most intensive tasks at startup is jitting your machine agnostic .NET assemblies into machine specific"
- ripley12 5y agoAh, I think I see what's going on. It's trivial to precompile .NET code with ReadyToRun today, but the Thundra post was written before that was possible. And it looks like the post above forgot to enable ReadyToRun (see the comments - not sure why it wouldn't be on by default). That said, in everyday console apps on modern hardware the JIT is super quick at startup. I guess Lambdas are running in more constrained environments...
- jabart 5y agoI run some C# lambdas using the HTTP API and that post is not accurate. Our Cloudwatch numbers are way lower on less memory used. Ways for better c# production startup (AWS or on Prem) * Compile in Release mode * Test Ahead-Of-Time (AOT) mode * Limit code size. The JIT reading 200mb+ of code will be slow compared to a 15mb deployment.