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

[V4] Support Native AOT trimming for DynamoDB DataModel #3606

Merged
merged 5 commits into from
Jan 16, 2025

Conversation

normj
Copy link
Member

@normj normj commented Jan 15, 2025

Description

Building off of the previous #3583 that added Native AOT for DocumentModel this adds support for DataModel.

The changes replaces the RequiresUnreferencedCodeAttribute with DynamicallyAccessedMembersAttribute with the DynamicallyAccessedMemberTypes parameter set to the required level of reflection needed. Any time the type in question is the POCO used by the callers to represent type the DynamicallyAccessedMemberTypes is set to All since full reflection is required by the library for loading and saving the type.

I got tired of adding all of the #if NET8_0_OR_GREATER conditional compilations throughout the code when using the trimming attributes like DynamicallyAccessedMemberTypes. I backported the trimming attributes into the ThirdParty.RuntimeBackports namespace so I could use the trimming attributes in all targets. As part of this I also removed #if NET8_0_OR_GREATER added for trimming attributes in Core and the DocumentModel as part of a global search.

Because of the S3Link feature that dynamically creates an S3Client I had to extend the GlobalRuntimeDependencyRegistry to allow registering the S3 client.

Using the following Lambda function using the DataModel library and deployed to Lambda I got the following cold start performances:

Without Native AOT: 1,697 ms
Native AOT: 509 ms

static IDynamoDBContext _context;

private static async Task Main()
{
    var ddbClient = new AmazonDynamoDBClient(RegionEndpoint.USWest2);

    _context = new DynamoDBContextBuilder()
                        .WithDynamoDBClient(() => ddbClient)
                        .Build();

    Func<string, ILambdaContext, Task<DataModelAotTest>> handler = FunctionHandler;
    await LambdaBootstrapBuilder.Create(handler, new SourceGeneratorLambdaJsonSerializer<LambdaFunctionJsonSerializerContext>())
        .Build()
        .RunAsync();
}

public static async Task<DataModelAotTest> FunctionHandler(string input, ILambdaContext context)
{
    var obj1 = new DataModelAotTest { Id = "1", Name = "Name1", FavoriteHobby = new Hobby { Name = "Hiking" } };

    await _context.SaveAsync(obj1);
    var obj2 = await _context.LoadAsync<DataModelAotTest>("1");

    return obj2;
}

Motivation and Context

#3475

Testing

  • Successful dry run
  • Built and publish as Native AOT that exercised the library to confirm no trimming warnings were produced.
  • Deployed and executed Native AOT Lambda function that used the library.

@@ -50,22 +48,25 @@ internal class SimplePropertyStorage
public MemberInfo Member { get; protected set; }
// Type of the property

#if NET8_0_OR_GREATER
[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor)]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is changing from PublicParameterlessConstructor to DataModelModeledType here intentional?

Copy link
Member Author

@normj normj Jan 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't remember why it was set to PublicParameterlessConstructor before but since the MemberType can represent a type from the user and this method relies on methods that also use the DataModelModeledType I need to make it consistent here.

@philasmar philasmar requested a review from peterrsongg January 15, 2025 18:27
@normj normj added the v4 label Jan 15, 2025
@normj normj merged commit 95f64da into v4-development Jan 16, 2025
1 check passed
@normj normj deleted the normj/v4-datamodel-aot branch January 16, 2025 17:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants