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

Memoizing results of traversals #89

Closed
kaushikcfd opened this issue Apr 25, 2022 · 3 comments · Fixed by #90
Closed

Memoizing results of traversals #89

kaushikcfd opened this issue Apr 25, 2022 · 3 comments · Fixed by #90

Comments

@kaushikcfd
Copy link
Collaborator

Not memoizing the results of the graph leads to unnecessary traversals. Some of the expression graphs I have consist of only 25% unique subexpressions i.e. paying unnecessarily for many traversals. I was hoping to implement a memorized version of the mappers (with the id as a default cheap cache-key). Some questions I had regarding this:

  • Does something like this already exist? (git grep says no)
  • Should this be implemented in the base mappers itself? (I'm leaning towards no as memorization wouldn't take into account global state, making it a non-trivial assumption.)
@inducer
Copy link
Owner

inducer commented Apr 25, 2022

I'm supportive of that idea.

  • Nothing of the sort exists.
  • What's the lifetime of the caches you are thinking of? (just that of the mapper, or longer? Loopy could hold longer-lived mappers, for those that are used often, if any.)

@kaushikcfd
Copy link
Collaborator Author

Thanks!

What's the lifetime of the caches you are thinking of

I was shooting for id as the cache key, which limits our cache lifetime to the lifetime of the expression being traversed. We could look into WeakKeyDictionary but I think relying structural equality comparisons on pymbolic expression objects could be dubious given #73.

@inducer
Copy link
Owner

inducer commented Apr 25, 2022

I think relying structural equality comparisons on pymbolic expression objects could be dubious given #73.

There exists #74, but I would tend to agree.

We could look into WeakKeyDictionary

My past experience with that has been that it's shockingly inefficient. That said, that experience comes from the ~Python 2.5 time frame, so a big grain of salt is advised :), although overall Python's refcounting scheme hasn't changed a great deal since then.

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 a pull request may close this issue.

2 participants