Closed kfrancis closed 3 months ago
We tried this, and we will keep it in mind for later, but for now there is hardly any benefit in this. Our deserializers only take string input, and consume an order of magnitude more memory than the overhead of the HTTP client. In other words: the potential gain from this is very limited. On top of this, we are forced to cast everything to strings anyways as to not break our API.
Once again, this may become beneficial in the future, but would require a major overhaul to be noticeable.
I was recently doing some improvement on my own HttpClient usage in libraries of our design after reading through https://xaml.dev/post/removing-memory-allocations-in-http-requests-using-arraypools, and someone on our team asked if we could improve allocation when utilizing this library. We are using this library to communicate with various FHIR endpoints, but we're finding there's a lot of allocation that seems that it could be optimized.
It does look possible when looking at HttpClientRequester
So, I've created a netstandard2.0 compatible version of
LimitArrayPoolWriteStream
that we use for this purpose (see article, we adapted this for use in netstandard2 which might be applicable here).And we use it in the following way (deserializing soap content):
In our case, the servers don't support sending back the Content-Length header - but that might be different in this case (and more efficient) when supported.