Expecting lots of push back to reduce push_back. These are extremely minor micro-optimisations, so feel free to just close the issue based on that.
PS: There are also a number of other minor optimisations whence elements are individually push_backed in succession, that could be replaced through a trivial vector::insert of a list (brace) initialisation.
What do you think? - Worth caring about / merging, or best to close a PR for such minor an optimisation?
Thanks for your contribution!
But yes, in general we only do optimization changes when a benchmark proves that it speeds up something relevant in a statistically significant way. Changes that span the entire tree are also discouraged.
I think your changes look okay in themselves, except one inside leveldb. That's a subtree, changes to third-party libraries should go to their upstream repository unless there's a strong reason to deviate from theirs.
What do you think? - Worth caring about / merging, or best to close a PR for such minor an optimisation?
I can't give this an concept ACK.
Thanks for your speedy feedback @laanwj. I've removed the third party lib change. Your lack of concept ACK… is that encouraging me to close this PR?
The UniValue changes are failing to compile; I don't think it has a constructor that could serve as a replacement for push_back.
Thanks @SamuelMarks, however I'm going to close this. As mentioned, if you're going to open optimization PRs, you should present some sort of benchmark. PRs that do repository wide refactoring, are also likely to disrupt other work. Regardless of any of that, these changes don't actually compile.
If you're planning on submitting more PRs, I'd suggest taking a look through CONTRIBUTING.md; then you can also avoid running into other issues, like modifying subtrees.