-
Notifications
You must be signed in to change notification settings - Fork 152
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
introduce slots #176
Merged
nikomatsakis
merged 16 commits into
salsa-rs:master
from
nikomatsakis:arc-all-the-things
Jul 2, 2019
Merged
introduce slots #176
nikomatsakis
merged 16 commits into
salsa-rs:master
from
nikomatsakis:arc-all-the-things
Jul 2, 2019
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
matklad
reviewed
Jun 21, 2019
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haven't looked in depth, but noticed a couple of odd things!
matklad
reviewed
Jun 21, 2019
@nikomatsakis wanna rebase? |
We could use e.g. intrusive-collections but from reading the docs and surveying the source it wasn't *obvious* to me that it had the right semantics.
The unsafe impl now asserts that the `DatabaseSlot` implementor type is indeed `Send+Sync` if `DB::DatabaseData` is `Send+Sync`. Since our query keys/values are a part of database-data, this means that `Slot` must be `Send+Sync` if the key/value are `Send+Sync`. We test this with a function that will cause compliation to fail if we accidentally introduce an `Rc<T>` etc.
nikomatsakis
force-pushed
the
arc-all-the-things
branch
from
July 2, 2019 10:49
44a8aa6
to
ed2bd52
Compare
@matklad been doing that =) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As discussed on Zulip this PR series optimizes our internal dependency data structures to avoid hashing of keys/values on query revalidation. My measurements found this to be approximately a ~35% win, though @matklad saw results up to 50%.
This PR does introduce some subtle logic around Send+Sync owing to the use of trait objects. It requires a bit of a hack to ensure that the database is Send+Sync iff the keys/values are Send+Sync. I found what feels like a decent solution to this problem by transmuting a
Arc<dyn Slot>
to aArc<dyn Slot + Send + Sync>
and using phantom-data to ensure that the composite is only send+sync if the keys/values are send+sync. The truth is that this is kind of overkill since slots are not exposed outside of the database, and if the keys/values are not send+sync, the database as a whole won't be -- but it still feels good to try and be precise here.