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

Avoid recursing into already substituted expressions #836

Merged
merged 2 commits into from
Feb 2, 2024

Conversation

fjetter
Copy link
Member

@fjetter fjetter commented Feb 2, 2024

Closes #835

This should avoid the worst case recursion pattern I described in #835

For the TPCH query this indeed reduces the number of substitute invocations (beyond the guard) from ~13M down to 17k

@fjetter
Copy link
Member Author

fjetter commented Feb 2, 2024

We are avoiding the runtime complexity problem with this change but for some queries the substitute operation is still the slowest part. During substitution there are many new objects created (even with #798) so many new _names have to be computed which is often a quite expensive operation

Copy link
Collaborator

@phofl phofl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thx! This is what I meant with caching in the issue

@phofl phofl merged commit 4fe73b1 into dask:main Feb 2, 2024
7 checks passed
@fjetter fjetter deleted the cache_substitude branch February 2, 2024 13:34
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 this pull request may close these issues.

Exponential runtime complexity for Expr.substitute
2 participants