Skip to content
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

Resolve 1371: sorting of public_keys is inefficient #1401

Closed
wants to merge 11 commits into from

Conversation

pmconrad
Copy link
Contributor

Implemented full solution for #1371
Also cherry-picked some changes from #1360

@pmconrad pmconrad added the 2f Testing Status indicating the solution is being evaluated against the test case(s) label Oct 25, 2018
@pmconrad pmconrad added this to the 201812 - Feature Release milestone Oct 25, 2018
@pmconrad pmconrad force-pushed the 1371_performance_opt_2 branch from 3826ef3 to bbb8730 Compare October 25, 2018 19:08
@pmconrad
Copy link
Contributor Author

Rebased and adapted new test case from #1384

@abitmore abitmore changed the title Resolve 1371 Resolve 1371: sorting of public_keys is inefficient Oct 25, 2018
@abitmore
Copy link
Member

I updated title of this PR to more descriptive since it helps when viewing PR list.

@abitmore abitmore changed the base branch from develop to performance_opt October 25, 2018 23:27
@abitmore abitmore changed the base branch from performance_opt to tmp-merge-perf-opt-to-develop October 25, 2018 23:35
@abitmore abitmore changed the base branch from tmp-merge-perf-opt-to-develop to develop October 26, 2018 00:08
@abitmore abitmore removed the hardfork label Oct 26, 2018
@pmconrad
Copy link
Contributor Author

It turns out that the check for irrelevant signatures relies on key ordering as well. Will have to refactor.

@pmconrad pmconrad force-pushed the 1371_performance_opt_2 branch from aeea794 to a3558aa Compare October 28, 2018 15:33
@pmconrad
Copy link
Contributor Author

pmconrad commented Oct 30, 2018

Test results so far indicate that this change does not result in significant speedup for replay, resync or resync with force-validate.

Version 2.0.180823 develop as of 2018-10-24 this pr
Replay 2:00:21 1:58:15 1:59:23
Resync 3:35:51 3:46:15 3:44:55
Resync (full validation) 7:15:06 7:21:59 7:18:52

(Resync was done at different times of day, fluctuations due to network conditions are to be expected.)

@pmconrad pmconrad mentioned this pull request Nov 1, 2018
17 tasks
@pmconrad
Copy link
Contributor Author

pmconrad commented Nov 2, 2018

Measurements have shown this to be a non-issue. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2f Testing Status indicating the solution is being evaluated against the test case(s)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants