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

perf: Remove expensive call to find matching in children #66

Merged
merged 4 commits into from
Jul 27, 2024

Conversation

jpedroh
Copy link
Owner

@jpedroh jpedroh commented Jul 27, 2024

During the merge process, given two nodes, left and right, we need to iterate over their children to determine how to merge them. In each iteration, we try to find a match for the current left child among the right children and vice versa. Previously, we were examining all captured matches across the entire program tree, which was heavily inefficient.

This PR changes the implementation to only consider the matches captured in the other node's children, significantly reducing the number of iterations required. Initial observations in empirical scenarios showed a performance boost of nearly 3x.

Copy link

codesandbox bot commented Jul 27, 2024

Review or Edit in CodeSandbox

Open the branch in Web EditorVS CodeInsiders

Open Preview

@jpedroh jpedroh merged commit 9ddddf8 into main Jul 27, 2024
7 checks passed
@jpedroh jpedroh deleted the perf-remove-expensive-call branch July 27, 2024 04:46
jpedroh added a commit that referenced this pull request Jul 27, 2024
…heck (#67)

Sure, here's the revised version with the term "auxiliary HashMap":

This work follows up on #66. Currently, the Matchings API provides a
quick way to retrieve a matching entry for two arbitrary nodes. However,
a common use case during the merge process involves finding a matching
entry for a node without prior knowledge of which other node it matches
with. While we have an API for this scenario, it is inefficient as it
may iterate over all matchings in the worst case.

This PR introduces an enhancement to address this inefficiency. The
approach involves storing an auxiliary HashMap where both the key and
value are nodes, say A and B. This way, there is an entry in the HashMap
only if there is a matching between node A and B. This allows us to
quickly check if a matching for node A exists by simply checking if an
entry is present in the HashMap. This change reduces the lookup time to
O(1), at the cost of additional memory usage and some performance
overhead in building and updating this auxiliary HashMap, which were
found to be negligible compared to the performance gains achieved.
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.

1 participant