UniValue copies have been a source of performance related bugs and regressions, so it would be good to remove the copy constructors.
This is the first change toward the goal. This change uses a const UniValue&
where possible.
See also:
UniValue copies have been a source of performance related bugs and regressions, so it would be good to remove the copy constructors.
This is the first change toward the goal. This change uses a const UniValue&
where possible.
See also:
const
will compile, but kill performance when std::move
or RVO is intended.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
See the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
Reviewers, this pull request conflicts with the following ones:
read_json
function into its own module by hebasto)outputs
argument for bumpfee
/psbtbumpfee
by rodentrabies)If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
I am actually not sure how to fix all copies. Sometimes the std lib will copy if asked to:
0std::vector<UniValue> a;
1std::vector<UniValue> b;
2a.insert(a.end(), b.begin(), b.end());
a.insert(a.end(), b.begin(), b.end());
In that case you can use
0a.insert(a.end(), std::make_move_iterator(b.begin()), std::make_move_iterator(b.end()));
But I there might still be case where copy constructor is necessary, I remember that I had difficulties in my old PR as well
std::pair<A, B> is different from std::map<A, B>::value_type (aka
std::pair<const A, B>). So fix the type to also avoid a copy.
🐙 This pull request conflicts with the target branch and needs rebase.