Hacker News Reader

Comment by romanhn | Hacker News Reader

As someone writing a .NET-based API hosted on AWS Lambda, I assure you, startup time matters a ton. I spent a bunch of time getting cold start time down to a semi-reasonable number, but there's still a ton of room for improvement. I for one am very much looking forward to progress on AOT Native.

View on HN

The "typical" in my comment was meant to take care of that part, I probably should have mentioned this explicitly. AWS Lambda is of course a case where startup time matters a lot, but it still leaves the common problem of ASP.NET that it was designed around a lot of reflection. My understanding is that this simply won't work with AOT out of the box unless you adapt all the places where you use reflection-based code. For example you'd need to use the source generator versions of JSON serialization and the EF Core DbContext in this case, with all limitations those have. But I'm not sure my understanding here is entirely correct or complete.

I don't know about ASP.NET, but the post says that Reflection.Emit is not available. Reflection.Emit is a namespace used for runtime code generation; I would assume most other parts of reflection are available, like with previous iterations of AOT support in .NET.

It is theoretically possible to have Reflection.Emit and DynamicMethod for less critical cases by using an interpreter - this happens in certain scenarios already.

I think you are correct. The DI container and JSON serialisation are two bigger areas that i suspect would need attention but as you say source generation solves the later and I think there is non reflection DI on the way if not already. I guess you would need to wait for any of the third party assemblies you depend on to allow for no reflection also...still a bit of a wait i think for my use case.

As someone writing a .NET-based API hosted on AWS Lambda, your case is quite different to a "typical ASP.NET hosted application", that can run for days between restarts.

I would like to host .net based api on google cloud run and azure container apps, which often will go to sleep after about 10 minutes without a request, so cold start time do matter quite a bit. I've done pretty extensive testing and see ~4-7 second cold starts with classic non aot mvc versus ~500ms with natively compiled golang/.net.

The reality of the cloud is that sleep & cold starts are very common and in fact necessary to run efficient systems. Half a second is acceptable but 4+ seconds is not and so aot is very important for future apps.

FWIW the problems with cold starts could also be solved at the platform layer. App startup is what typically dominates cold start times and there's creative ways to potentially frontload that, serialize the state, and treat all invocations as "warm".

The good news is that .net7 aot supports console apps so lamdas can already be native aot. Json serialization was a concern of mine, but it was surprising easy to get working with very minor changes in the call. If I were building lambdas would move it asap.

Lol snap

No, snap startups have an even worse startup time.

Reply on news.ycombinator.com