-
Notifications
You must be signed in to change notification settings - Fork 49
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
AOT support for dotnet clients #424
Comments
@SamuelCox you can exclude certain libraries from trimming when using native AOT. In your csproj file you can either set the
Use with care - If you are going to take this approach, I'd recommend testing pretty extensively. But it does give you the ability to simply exclude libraries that aren't yet AOT friendly from being trimmed. |
Hmm, that's a good workaround which we will have to investigate once dotnet 8 comes out. Trimming stops code from being eliminated that the compiler thought was dead, but actually could have been called into dynamically by reflection. But if I remember correctly, aren't there whole reflection APIs that are just outright not supported in AOT as well? That presumably wouldn't be solved by trimming right? Am I misremembering how AOT works? |
There's a related issue #370 regarding trimming and the use of reflection & dynamic assemblies in the client, that includes a workaround pending a fix in ILLink |
I'd have to do some experimenting myself, but I believe the client's entire JSON (de)serialization stack (Utf8Json) is fundamentally incompatible with AOT due to its use of runtime dynamic code generation. Probably other reflection uses around the client relating to field inference and such that'll be incompatible too. So I don't believe this will be an easy shift. |
Yeah, that was my understanding, thanks. Agree that its not an easy shift, even if opensearch was compatible we'd have to rewrite significant parts of our stack. But for our company, we operate at scale and are all-in on serverless. So AOT represents both a massive cost saving in AWS billing, and a significantly better UX for customers |
Its interesting that you use Utf8Json, I note that the official ES library (from before OpenSearch forked it) has said that they are moving to System.Text.Json as Utf8Json is no longer actively maintained Is this not the case for this library? Would my company benefit from moving to the lower level opensearch driver, or does that also use Utf8Json under the hood? |
OpenSearch.Net was forked from the 7.12 branch (at https://github.com/elastic/elasticsearch-net/tree/8d64d4c026ff116eb45e83c05610b6ac430b4376) of ES rather than v8 or main, to mostly match up with the point at which the server was forked (~7.10). So those changes were not carried over, there was another issue regarding adding support for |
Is your feature request related to a problem? Please describe.
I work at a company that makes heavy use of the dotnet clients in our lambdas. Currently we are blocked from upgrading to AOT when dotnet 8 comes out because this library, as far as I am aware, does not support AOT.
Describe the solution you'd like
Dotnet clients, or at least a dotnet client library, to support AOT compilation.
Describe alternatives you've considered
Roll our own opensearch library. Move to rust or some other AOT compiled language.
Additional context
None that I can add in public.
The text was updated successfully, but these errors were encountered: