You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was investigating the performance characteristic of a cql algorithm we had authored, and noticed that if i passed in a particularly ordered list of expressions to the cqlengine's evaluate, i would get better performance characteristics for the same results.
We have many algorithms that have dozens of defines calculating sub-sections of logic that are then needed in a final "culmination statement" (usually a long boolean expression). The intermediate defines also have to be queried for operational and support reasons. So for our use case, an unbounded cache gives optimal performance for very little actual effect on our memory profile.
I repackaged my jar to manually override the class with a Cache implementation with unbounded maps, and it produced the expected results in a significantly faster timeline.
One solution could be allowing the cache to have its backing maps configured, but i think the best solution would be to refactor the Cache to be an interface, with the current implementation being the default impl. This would allow users to back this cache with whatever technologies make the most sense for the stack they are running with, and also encode other logic in if needed.
I'm very open to discussion on the topic, and am interested in providing a pull if refactoring as an interface makes sense to others.
The text was updated successfully, but these errors were encountered:
I was investigating the performance characteristic of a cql algorithm we had authored, and noticed that if i passed in a particularly ordered list of expressions to the cqlengine's
evaluate
, i would get better performance characteristics for the same results.Looking into it more deeply, i realized that the
Cache
implementation used for expression caching is ONLY caching the 15 most recent expressions(per library). Source: https://github.com/cqframework/clinical_quality_language/blob/master/Src/java/engine/src/main/java/org/opencds/cqf/cql/engine/execution/Cache.java#L36We have many algorithms that have dozens of defines calculating sub-sections of logic that are then needed in a final "culmination statement" (usually a long boolean expression). The intermediate defines also have to be queried for operational and support reasons. So for our use case, an unbounded cache gives optimal performance for very little actual effect on our memory profile.
I repackaged my jar to manually override the class with a
Cache
implementation with unbounded maps, and it produced the expected results in a significantly faster timeline.The problem i face is that i have no way to configure the state with my version of the cache, i had to resort to class loading shenanigans since the State object directly instantiates the cache: https://github.com/cqframework/clinical_quality_language/blob/master/Src/java/engine/src/main/java/org/opencds/cqf/cql/engine/execution/State.java#L24
One solution could be allowing the cache to have its backing maps configured, but i think the best solution would be to refactor the Cache to be an interface, with the current implementation being the default impl. This would allow users to back this cache with whatever technologies make the most sense for the stack they are running with, and also encode other logic in if needed.
I'm very open to discussion on the topic, and am interested in providing a pull if refactoring as an interface makes sense to others.
The text was updated successfully, but these errors were encountered: