Based on an investigation of the differences between SUSHI v2.10.2 and v3.3.0, there are several contributors to longer runtime for the sample repo.
One is the validation of path rules during Instance export. Path rules are validated with an assigned value of null. It may be the case that these rules do not need to be validated at all, and that they can be skipped. If there are cases where it is necessary to validate a path rule, it may be possible to do so with a function that is less expensive than StructureDefinition.validateValueAtPath.
Another is that when many instances of the same StructureDefinition are created, the StructureDefinition is fished up and created fresh for each instance. This means that operations such as unfolding elements will be repeated when rules are validated. In this case, ElementDefinition.unfold ends up using a large amount of process ticks. It may be possible to reuse a StructureDefinition for each instance being created. There may be limitations to this, though: it may only be possible to reuse a StructureDefinition of a core FHIR resource.
As another potential optimization, it may be possible to skip setImpliedPropertiesOnInstance when creating an instance of a core FHIR resource. This is because core FHIR resources do not have any fixed or pattern values on their elements.
See zulip thread for original discussion. A sample repo was provided to perform the analysis that led to these findings. Sample performance logs for the versions being compared are attached: v2.10.2-performance.txt v3.3.0-performance.txt
Based on an investigation of the differences between SUSHI v2.10.2 and v3.3.0, there are several contributors to longer runtime for the sample repo.
One is the validation of path rules during Instance export. Path rules are validated with an assigned value of
null. It may be the case that these rules do not need to be validated at all, and that they can be skipped. If there are cases where it is necessary to validate a path rule, it may be possible to do so with a function that is less expensive thanStructureDefinition.validateValueAtPath.Another is that when many instances of the same StructureDefinition are created, the StructureDefinition is fished up and created fresh for each instance. This means that operations such as unfolding elements will be repeated when rules are validated. In this case,
ElementDefinition.unfoldends up using a large amount of process ticks. It may be possible to reuse a StructureDefinition for each instance being created. There may be limitations to this, though: it may only be possible to reuse a StructureDefinition of a core FHIR resource.As another potential optimization, it may be possible to skip setImpliedPropertiesOnInstance when creating an instance of a core FHIR resource. This is because core FHIR resources do not have any fixed or pattern values on their elements.