-
Notifications
You must be signed in to change notification settings - Fork 109
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
datastore: insert via BSATN instead of via PV #2069
Conversation
5df3305
to
5dfebdd
Compare
374c094
to
5df4fc2
Compare
8275279
to
4af0705
Compare
which asserts that `table.insert(..)` does the same as using the bsatn path. Sprinkles various `Debug, PartialEq, Eq` derives to achieve this. Also uses `confirm_insertion` more to get that more under test. 2. Review and justify some unsafes.
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.
I have only reviewed the table
and locking_tx_datastore
changes with any particular care; everything else I glanced at, but didn't worry too much about, on the grounds that it's all safe code, it's barely changing and it's tested. The table
and datastore
parts I looked at quite carefully. I agree with your safety reasoning, and your benchmark results speak for themselves. I've left a few minor comment-related requests, like I always do. Great work on this! And thanks again for writing such a detailed PR description; it made review much smoother.
9c1c762
to
cb64434
Compare
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.
Approved pending the suggested change. I have only reviewed the files I'm the owner for.
Description of Changes
This PR changes the structure of the datastore to insert via BSATN rather than a PV. But this isn't entirely true, we just use the fast-path for BSATN -> BFLATN but in the general case we still do BSATN -> PV -> BFLATN. Later, I'll fully remove the temporary step. One of the other required changes here is that we write and generate sequence values directly in BFLATN.
Fixes #2017.
Perf numbers on master
with this PR:
That is, this removes ~0.4516s and 0.3887s from the benchmarks respectively.
Flamegraph of
InstanceEnv::insert
:Full flamegraph: https://flamegraph.com/share/14b571da-c9ba-11ef-9832-26c3e5347170
The next step after this PR is to avoid the pointer map in case there is a unique index.
After that, the next step is to add an
update
ABI.API and ABI breaking changes
None
Expected complexity level and risk
4 -- limited scope, but lots of unsafe code and complicated logic.
Testing
The internal
spacetimedb_table
tests still use the oldtable.insert
, so the new path. To compensate for this, without duplicating tests, a new proptestinsert_bsatn_same_as_pv
is added asserting that the result and side-effects of inserting via PV and BSATN are the same. Moreover, both insert paths try to share as much code as possible to improve test coverage. The higher level tests, starting withMutTxId
now use the new path. Over time, we can replace the remaining old paths with the new and then move all tests to the new as well.Reviewer notes
I would recommend reviewing in this order:
spacetimedb_table
locking_tx_datastore
InstanceEnv
estimation.rs
that were unfortunately necessary.Review notes for Tyler
In
traits.rs
the following changes:insert_mut_tx
changes from: