-
Notifications
You must be signed in to change notification settings - Fork 38
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: do not recompute the intersection when backtracking #171
Conversation
Let me know if my understanding is correct. This PR is a memory/compute trade off. Instead of only keeping the latest assignments intersection, we keep a record of intersections at each stage by storing it in dated_derivations. This change prevents the need to recompute intersections when backtracking since dated derivations also store the intersection at the corresponding time. I suppose |
Great work, that makes the two bad cases i test a good bit faster:
|
@mpizenberg, yes your understanding is correct.
Theoretically yes. But then |
I fixed the comment and improved some redundancy. This should be ready for a final review. I also generated a Ron file inspired by the example I've been using for testing. slow_135_0_u16_NumberVersion.txt (change from txt to ron to use). It's runtime gets about 50% faster after this PR. How realistic is it 🤷 . |
…#171) * perf: do not recompute the accumulated_intersection when backtracking * more correct comment message * make things dry again
This eliminates the intersection calls made when backtracking. Unfortunately, it is within the noise on all of my standard benchmarks. However it does cause dramatic speedups for #135 (comment) (I really need to make a ron file of this, so that I can add it to my normal benchmarking suite.)
Based on the flame graphs we reviewed in Office Hours today I suspect this will make a solid difference for @konstin workloads. It also unlocks more impactful simplifications in satisfier search.