-
Notifications
You must be signed in to change notification settings - Fork 594
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
Non-determinstic poor performance with nested If conditions #3717
Comments
In a way this doesn't surprise me. I need to track down what is causing this as we try to avoid these massive complications as much as possible... we also try set limits on how many permutations we will evaluate. That being said there are a few areas where we may still being doing needless permutations. I'll be looking into this today. |
I see what you are saying now about the random parts. |
Also looks like installing pycosat helps performance a lot for this scenario. |
Yep, I can confirm that after installing pycosat, at least with the two hash seeds in the examples above I see the "fast" seed go down from ~4 seconds to ~3 seconds, and more importantly the "slow" seed drops from around ~75 seconds to ~3 seconds too. Without pycosat
With pycosat
|
I've been debating including it as a dependency based on this improvement |
CloudFormation Lint Version
cfn-lint 1.15.1
What operating system are you using?
Linux (Fedora 40 x86_64)
Describe the bug
When nested Fn:If conditions are used (or possibly just large numbers of Fn:If conditions) cfn-lint performance can degrade severely.
Processing the attached template can range from seconds, to over a minute for the attached example, the original full template, which has multiple nested Fn:If cases has been observed to take up to 8 minutes to process in some cases.
I have figured out that I am able to achieve repeatable processing times by forcing specific python hash seeds, in the following examples the hash seeds are random test values that I found that trigger both fast and slow processing, but the overall time can vary widely depending on the hash seed, ie there's not just one "slow" and one "fast" case.
Based on a few stack traces taken from "slow" examples I suspect that the issue may be related to sympy2's DPLL implementation, but that's just a guess based on a handful of stack traces, and the issue could also be higher up in the call chain.
Removing the nesting of the If condition from the template does appear to significantly improve both the absolute performance, and the variability, but I'm not sure whether that's specifically related to the nesting of the If conditions, or just the total number of possible condition combination branches.
This issue may be somewhat related to the previously addressed #2597
Expected behavior
Template processing should ideally be single, or low double digits seconds at most, but regardless of absolute performance the time required to process a given template shouldn't change by orders of magnitude between runs based on random factors like the python hash seed.
Reproduction template
The text was updated successfully, but these errors were encountered: