Eliminate copies when accessing values from Bson types

[tgoyne]

Returning things by value performs a deep copy, which is very expensive when those things are also bson containers.

Re-align the naming with the conventional names for the functions rather than being unnecessarily different.

[coveralls-official]

Pull Request Test Coverage Report for Build thomas.goyne_193

Details

• 82 of 82 (100.0%) changed or added relevant lines in 9 files are covered.
• No unchanged relevant lines lost coverage.
• Overall first build on tg/bson-copy at 90.922%

---

Totals
Change from base Build 2062:	90.9%
Covered Lines:	238310
Relevant Lines:	262105

---

💛 - Coveralls

[jedelbo]

@tgoyne so, in which actual use cases can you measure a performance degradation? I have not seen a degradation in the App use of things.

[tgoyne]

The uses in App don't involve any nested collections, but we also use the bson types in our mongo client wrapper which can receive arbitrarily deeply nested data if that's what the user has.

[tgoyne]

Here is a trivial benchmark which shows a performance regression:

using namespace realm::bson;
static const std::vector<char>& read(const Bson& bson)
{
    if (bson.type() == Bson::Type::Array) {
        return read(static_cast<const BsonArray&>(bson)[0]);
    }
    return (static_cast<const std::vector<char>&>(bson));
}

TEST_CASE("bson") {
    std::vector<char> data(1024 * 1024, 'a');
    BsonArray nested({BsonArray({BsonArray({BsonArray({Bson(data)})})})});
    BENCHMARK("read nested data") {
        REQUIRE(read(nested) == data);
    };
}

41us with 13.27.0 and 255us with 14.0.0.

The API changes are also just a significant negative which makes working with the type much more awkward.

[jedelbo]

@tgoyne got your point. I was not aware that the type had a wider use. I did not think this API was part of our public API.