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

Allow a custom implementation of the State Cache #1486

Open
Zylox opened this issue Jan 9, 2025 · 0 comments
Open

Allow a custom implementation of the State Cache #1486

Zylox opened this issue Jan 9, 2025 · 0 comments

Comments

@Zylox
Copy link
Contributor

Zylox commented Jan 9, 2025

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#L36

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.

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.

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

No branches or pull requests

1 participant