-
Notifications
You must be signed in to change notification settings - Fork 263
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
DeleteVersion is quite slow #26
Comments
Pushed a new branch, which seems slower for memdb, but faster for goleveldb: benchmarks:
sdk2-benchmarks:
|
Notes on history size... Keep last 20 blocks:
with history 100 (no cleanup over benchmark size):
|
Did you compile with build tag +gcc? Looks like leveldb may be using goleveldb since it didn't find cleveldb? (Just guessing based on number similarity between goleveldb and leveldb metrics) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While reworking the tests for #25, I decided to replicate the proper orphan cleanup. That is, after
SaveVersion(version+1)
, I also callDeleteVersion(version-1)
.Here are the rough results from local benchmarks, without
DeleteVersion
(no cleanup):And with
DeleteVersion
(as we use it min the sdk):context:
times for update is each call to update, committing to "disk"/"memdb" every 100 updates
time for block is the total time to call query/set on 100 different keys.
all of this is done with a db prep-populated with 100k key/value pairs
(the code is
<dbtype>-<initial size>-<block size>-<key bytes>-<value bytes>
)We can see that adding the
DeleteVersion
cleanup triples the time.I would show numbers for goleveldb, except that it crashes.... #27
The text was updated successfully, but these errors were encountered: