Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Native AOT #245

Open
wahmedswl opened this issue May 12, 2024 · 9 comments
Open

Native AOT #245

wahmedswl opened this issue May 12, 2024 · 9 comments

Comments

@wahmedswl
Copy link

Hi!

Thanks for this awesome library. Does this support Native AOT?

Thanks

@firenero
Copy link
Contributor

Hi @wahmedswl. Unfortunately, Native AOT is not supported. We use runtime code generation (System.Reflection.Emit) that is not compatible with the Native AOT. There could be more incompatibilities but I've never done a full evaluation and don't know the effort required to make EfficientDynamoDb Native AOT compatible.

Do you use the library in Lambda with AOT runtime for better cold starts? If not, do you mind sharing where did you plan to use the Native AOT?

@wahmedswl
Copy link
Author

@firenero We are using AWS Lambda and yes we are evaluating Native AOT to get better cold-start time. We are evaluating EfficientDynamoDb as well to see how it will help. Following is the screenshot with aws sdk and invoking only dynamodb (Above is .Net 8.0 and below is for .Net 8.0 Native AOT).

image

@firenero
Copy link
Contributor

As far as I understand from .NET AWS SDK GitHub issues, they only support low-level API because it doesn't use reflection:

There is a draft PR that's supposed to improve Native AOT compatibility but I haven't looked into what it actually does yet:

I think it should be relatively easy to add Native AOT support for low-level APIs in EfficientDynamoDb as well because there is no reflection used. I always tried to avoid using the low-level APIs in production code because it's annoying to deal with so I don't know how useful it would be. @wahmedswl is it something that sounds beneficial for your use-case?

@wahmedswl
Copy link
Author

@firenero If we don't trim, it's only size isn't it? So, we can add EfficientDynamoDb to no trim list, then it should work isn't it?

@firenero
Copy link
Contributor

I haven't checked it myself but according to aws/aws-sdk-net#2542 (comment) and the following comments you also have to exclude some system code. Also, I'm not sure that it will be enough because Limitations of native AOT deployment states that runtime code generation is not supported. We at least use System.Reflection.Emit for converters but there is a chance that something else is incompatible.

I would like to have Native AOT supported though. So it would be great if you're up to testing it and describing required changes to make it work (or submitting a PR). That said, most likely we need to keep codegen for performance reasons so most likely we'll need some compilation flags to support both cases.

@Dreamescaper
Copy link

Dreamescaper commented Jun 3, 2024

In order to be fully AOT-compatible, it would probably require a source generator (similar to what System.Text.Json has).
On the other hand, maybe this source-generator could even replace Reflection.Emit approach for non-AOT scenarios.

Reflection itself is somewhat supported with AOT, but traversing the properties is not.
Also, lots of MakeGenericType calls wouldn't work with AOT, and they are used extensively with Convertors.

I wanted to take a quick look how hard would it be to add AOT support, but the project doesn't compile with "net8.0" target framework :).

@wahmedswl
Copy link
Author

Dapper also has AOT version which they based on the Interceptors, its also new and experimental. https://aot.dapperlib.dev/

@firenero
Copy link
Contributor

firenero commented Jun 8, 2024

@Dreamescaper yes, I think source-gen (or interceptors as mentioned by @wahmedswl) is the way to go and it should be used for non-AOT as well just for performance gains. There is a PR #237 that compiles for .net8 and it would be great if you can take a look. There are a couple bugs with the thread-safety in converters in this PR that I mentioned in comments but it should be good enough for trying out AOT. Please let me know if you're up for looking into AOT support using this branch.

@Dreamescaper
Copy link

Yes, I'll take a look. Seems like most of AOT incompatibilities are in Converter Factories and in Metadata types.
I would suggest the following plan of actions (similar to how it is done for System.Text.Json).

  1. Annotate all AOT incompatible code.
  2. Extract all the code, which is responsible for building the metadata to some separate type(s), with abstract base class, e.g. AbstractMetadataBuilder. Reflection and emit approach would the default implemetation of this MetadataBuilder, but it should be possible to provide a custom reflection-free implementation of it for a specific type.
  3. Create a source generator, which would generate a reflection-free MetadataBuilder for provided types.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants