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

Extreme validation slowdown due to changed primitive type check implementation #6252

Closed
Boereck opened this issue Aug 28, 2024 · 2 comments · Fixed by #6253
Closed

Extreme validation slowdown due to changed primitive type check implementation #6252

Boereck opened this issue Aug 28, 2024 · 2 comments · Fixed by #6253

Comments

@Boereck
Copy link
Contributor

Boereck commented Aug 28, 2024

Describe the bug
We noticed an extreme slowdown of resource validation in our project when switching to HAPI 7.4.0. Instead of minutes the validation takes hours. We profiled the application and found out that almost 100% of the time was spent in VersionSpecificWorkerContextWrapper#isPrimitiveType(String). The code is always traversing all StructureDefinitions to check if any type that is primitive has a matching name.

To Reproduce
Validate a resource with lots of StructureDefinitions available to the ValidationContext, triggering isPrimitive call. The simplest is a CodeSystem, since constraint csd-1 triggers a lot of those calls when evaluating the isDistinct function.

Expected behavior
The expected behavior would be a reasonable evaluation time of isPrimitive(String).
We would suggest to add a field of type Set<String> of names of primitive types to VersionSpecificWorkerContextWrapper to cache the names of all primitive types, similar to how it is done for all known StructureDefinitions already.

If it is wanted, we can work on a PR implementing the suggested solution.

Environment (please complete the following information):

  • HAPI FHIR Version 7.4.0
@jamesagnew
Copy link
Collaborator

Thanks for the submission! That does sound like an issue. For what it's worth, a PR implementing the fix you propose would be gladly accepted.

@jamesagnew
Copy link
Collaborator

Possibly related to #6091

Boereck added a commit to Boereck/hapi-fhir that referenced this issue Aug 28, 2024
…ifhir#6252)

Caching primitive type names for faster lookup if a type is primitive.
Boereck added a commit to Boereck/hapi-fhir that referenced this issue Sep 2, 2024
…ifhir#6252)

Caching primitive type names for faster lookup if a type is primitive.
Boereck added a commit to Boereck/hapi-fhir that referenced this issue Sep 10, 2024
…ifhir#6252)

Caching primitive type names for faster lookup if a type is primitive.
Boereck added a commit to Boereck/hapi-fhir that referenced this issue Sep 12, 2024
…ifhir#6252)

Caching primitive type names for faster lookup if a type is primitive.
Boereck added a commit to Boereck/hapi-fhir that referenced this issue Sep 12, 2024
…ifhir#6252)

Caching primitive type names for faster lookup if a type is primitive.
Boereck added a commit to Boereck/hapi-fhir that referenced this issue Sep 20, 2024
…ifhir#6252)

Caching primitive type names for faster lookup if a type is primitive.
Boereck added a commit to Boereck/hapi-fhir that referenced this issue Oct 1, 2024
…ifhir#6252)

Caching primitive type names for faster lookup if a type is primitive.
Boereck added a commit to Boereck/hapi-fhir that referenced this issue Oct 8, 2024
…ifhir#6252)

Caching primitive type names for faster lookup if a type is primitive.
jamesagnew added a commit that referenced this issue Oct 8, 2024
…) (#6253)

* Improving performance, using caching when testing for primitives (#6252)

Caching primitive type names for faster lookup if a type is primitive.

* Credit for #6253

---------

Co-authored-by: James Agnew <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants