Closed KLazarov closed 3 months ago
@KLazarov
Thanks for reaching out.
The tests you've attached show indeed a big difference in performance, however FhirObjectSerializerTest
doesn't only differ in the fact that you've set a type compared to FhirR4SerializerTestv2
.
In the FhirObjectSerializerTest
you do not use options (new JsonSerializerOptions().ForFhir(ModelInfo.ModelInspector)
), which contains all the FHIR logic of the Deserializer (all the parsing from string to DateTime, Int, Bool, etc. But also all the FHIR extension logic, validation, and other checks. This takes time. So it's not a fair comparison.
The way you test now, you just get a dictionary returned that corresponds to the Json file, it doesn't parse to our FHIR Poco models.
You can still improve the time of deserialization by turning off the validator in the settings (set it to null) if you want, but it will never come close to parsing json to a dictionary without any FHIR logic.
If you have concrete ideas on how to speed up serializer further, please let us know.
Maybe we can utilize System.Text.Json more in serializers to improve the speed. However, this currently doesn't have our top priority.
If you would like to discuss this, re-open the issue. We can do some design discussion and you can create a PR afterwards.
Describe the bug When I deserialize a large (1-4MB) Bundle resource the performance goes down 10-20x times. A 4MB Bundle can take up to 400ms to deserialize.
If I instead used dynamic object instead of Bundle, the performance is closer to 11ms for the same 4MB Bundle.
To Reproduce Steps to reproduce the behavior:
Expected behavior The deserializer should not lose 95%+ of it's performance just because I have set the type.
Code
The code also prewarms the Bundle deserialization as otherwise it can go up to 1.5 seconds. All tests were done on a AMD 5900x CPU, 64GB 3600MHz RAM, and Windows 11. The file is loaded only once in memory.
Results
With custom Bundle that we use at work:
With valuesets.json:
Version used: