4 ms·

I think typical ASP.NET applications likely won't use AOT in the near future. There is quite some "magic" in ASP.NET that I suspect won't work out of the box wi

I think typical ASP.NET applications likely won't use AOT in the near future. There is quite some "magic" in ASP.NET that I suspect won't work out of the box with AOT because it is heavily reflection-based. And while there are solutions for cases like JSON serialization, as far as I understand they require writing different code right now, so it's not automatic. AOT is much, much more interesting for cases where startup time matters, and ASP.NET usually isn't such a case. But I can imagine that it will be much more useful and easier to implement for smaller, focused tools that don't use that much reflection-based framework code. CLI tools might be the ideal case for trying this out.

ewjt 4y ago
Serverless hosting (ie. AWS Lambda) makes ASP.NET a primary use case for AOT because cold startup times cripple performance and increase cost. I suspect they’re just not ready yet and targeting the easy use cases (console apps).
romanhn 4y ago
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.
- tmitchel2 4y ago
  Lol snap
  - fnord123 4y ago
    No, snap startups have an even worse startup time.
- SideburnsOfDoom 4y ago
  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.
  - ledgerdev 4y ago
    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.
- fabian2k 4y ago
  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.
  - paavohtl 4y ago
    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.
    - kevingadd 4y ago
      It is theoretically possible to have Reflection.Emit and DynamicMethod for less critical cases by using an interpreter - this happens in certain scenarios already.
  - tmitchel2 4y ago
    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.
- ledgerdev 4y ago
  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.
- phillipcarter 4y ago
  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".
tmitchel2 4y ago
Using ASP.NET with AWS Lambda or any other FAAS is a concrete scenerio. Startup time for that is critical.

ewjt 4y ago

Serverless hosting (ie. AWS Lambda) makes ASP.NET a primary use case for AOT because cold startup times cripple performance and increase cost. I suspect they’re just not ready yet and targeting the easy use cases (console apps).

romanhn 4y ago

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.

tmitchel2 4y ago
Lol snap
- fnord123 4y ago
  No, snap startups have an even worse startup time.
SideburnsOfDoom 4y ago
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.
- ledgerdev 4y ago
  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.
fabian2k 4y ago
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.
- paavohtl 4y ago
  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.
  - kevingadd 4y ago
    It is theoretically possible to have Reflection.Emit and DynamicMethod for less critical cases by using an interpreter - this happens in certain scenarios already.
- tmitchel2 4y ago
  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.
ledgerdev 4y ago
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.
phillipcarter 4y ago
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".

tmitchel2 4y ago

Using ASP.NET with AWS Lambda or any other FAAS is a concrete scenerio. Startup time for that is critical.