Significant Performance difference between Kiota-based client vs using HttpClient directly

[hlavingia]

We've observed a noticeable performance difference between using the Kiota-based C# client and making direct HttpClient calls with manual deserialization via System.Text.Json. Is there a way to optimize Kiota client function calls to bring performance comparable to using HttpClient directly? Here, based on our performance tests, HttpClient is performing 2X faster than consuming kiota client auto generated for the service.

Following versions are consumed for Kiota client.

dotnet tool: microsoft.openapi.kiota: 1.27.0

To generate Kiota client
PackageVersion Include="Microsoft.Kiota.Abstractions" Version="1.19.0"
PackageVersion Include="Microsoft.Kiota.Http.HttpClientLibrary" Version="1.19.0"
PackageVersion Include="Microsoft.Kiota.Serialization.Json" Version="1.19.0"

For Kiota client project
PackageVersion Include="Microsoft.Kiota.Serialization.Form" Version="1.19.0"
PackageVersion Include="Microsoft.Kiota.Serialization.Multipart" Version="1.19.0"
PackageVersion Include="Microsoft.Kiota.Serialization.Text" Version="1.19.0"

[baywet]

Hi @hlavingia
Thank you for using kiota and for reaching out.

Could you please provide comparisons with performance tests for different aspects to try an narrow it down please?

e.g.:

1. serializing the same object through STJ and kiota serialization infrastructure
2. deserializing the same object through STJ and kiota deserialization infrastructure
3. create the HttpRequestMessage through kiota and manually.

Thanks!

[hlavingia]

Hi @baywet, I’d like to reopen this issue as I now have the requested performance comparison numbers and they show a significant difference between Kiota-based client and direct HttpClient usage.

1. Serializing the same object through STJ and kiota serialization infrastructure
   
2. Deserializing the same object through STJ and kiota deserialization infrastructure.
   
3. Create the HttpRequestMessage through kiota and manually.
   

[baywet]

Thank you for the additional information.

What would be interesting would be to upload the benchmark to a temporary repository so we can get better insights on how the comparison is done. And what could explain the difference.

In the deserialization scenario, there's going to be a bit more memory pressure that we would like for the kiota models because of this pattern:

public override IDictionary<string, Action<IParseNode>> GetFieldDeserializers()
        {
            return new Dictionary<string, Action<IParseNode>>(base.GetFieldDeserializers())
            {
                { "attachments", n => { Attachments = n.GetCollectionOfObjectValues<global::Graphdotnetv4.Models.Attachment>(global::Graphdotnetv4.Models.Attachment.CreateFromDiscriminatorValue)?.AsList(); } },
                { "bccRecipients", n => { BccRecipients = n.GetCollectionOfObjectValues<global::Graphdotnetv4.Models.Recipient>(global::Graphdotnetv4.Models.Recipient.CreateFromDiscriminatorValue)?.AsList(); } },
                { "body", n => { Body = n.GetObjectValue<global::Graphdotnetv4.Models.ItemBody>(global::Graphdotnetv4.Models.ItemBody.CreateFromDiscriminatorValue); } },
//.....
            };
        }

This is because:

1. a dictionary gets instantiated for each model that gets deserialized
2. the lambdas access the instances, so the compiler needs to capture the context

Ideally this would be static (although it poses challenges with inheritance scenarios), and accept the model as a parameter somehow so lambdas can also be static. But changing all of that now would most likely be a breaking change.

I'm not sure why there's such a difference in the serialization scenario.

As for the Http scenario, could the difference be explained by the one we see with the serialization and/or? (I'd be curious to see if there's any difference for a GET with no content response).

Let me know if you have any additional comments or questions.