-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Conversation
…by way of paritytech/parity-common#257 by @ordian.
* master: Clarify what first_block `None` means (#11269) removed redundant VMType enum with one variant (#11266) Ensure jsonrpc threading settings are sane (#11267) Return Ok(None) when the registrar contract returns empty slice (#11257) Add a benchmark for snapshot::account::to_fat_rlps() (#11185) Fix misc compile warnings (#11258) simplify verification (#11249)
(Sorry for the stupid question) Do we have any metric or tests for it? I mean, do we understand, how will this affect client's performance? @ordian |
Sort of. Both me and @ordian have been running block import tests over the last few days. Here are mine from last night, importing 5k blocks from approx mid-chain: Master:
Upstream rocksdb:
I think @ordian's results are similar. |
* master: Upgrade trie-db to 0.16.0. (#11274)
@grbIzl I'm seeing 20% improvement on |
More benchmarks, now also comparing a master build from today (Nov 21, 2019), after the new trie landed (referred to below as "fast trie", but it's actually a little slower, cc @cheme @jimpo): Upstream rocksdb
Upstream rocksdb + fast trie
Forked rocksdb (master, Nov 20)
Forked rocksdb + fast trie (master, Nov 21)
I also ran the same set of benchmarks with more verifier threads (8), but it has little impact. Upstream rocksdb + 8 verif threads
Upstream rocksdb + fast trie + 8 verif threads
Forked rocksdb + 10 verif threads (master, Nov 20)
Forked rocksdb + fast trie + 8 verif threads (master, Nov 21)
|
That's very interesting, trie db crate improvement are mainly on triedb iterator, It could be rather simple to test: just put back the old 'decode' function in node_codec and see if it fix the perf (decode still exist in the trait but with a default implementation that call the 'build' function). |
I did this and but my micro-benchmark did not show any meaningful regression, not sure if my benchmark is bad perhaps. :/ |
Thanks for checking 👍 , should be from somewhere else then :\ . |
I think it will be necessary to test the build on the architectures aarch64, armv7, i386. And also on Windows and Mac platforms. |
build test's https://gitlab.parity.io/General-Beck/parity-ethereum/pipelines/70139 |
Why not the same version on both? i.e. clang-9? |
During the discussion phase, I and @TriplEight do not mind using stable clang-9. We only need confirmation from the developers. and so that it does not interfere with other projects |
Hmm, how do you mean, "developers"? And I'm not sure which other projects share the same CI setup, can you elaborate? |
Please let us know when the work is completed, thanks! |
build passed |
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.
Great! Do we have some benchmarks? NVM just saw in the comments.
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.
nice, LGTM
I've talked to the devops team about running the import benches on a daily basis or at least on-demand to track perf regressions, will let you know once it's done. |
…by way of paritytech/parity-common#257 by @ordian.