Fix performance regression introduced with the parsing callback feature.

[aburgh]

Hi Niels,

Upon reviewing the changes I made during our exchange regarding the performance of the callback feature, these two moves appear to account for all of the improvement to get performance back to the non-callback version.

Regards,

Aaron

[coveralls]

Coverage remained the same at 99.68% when pulling ea3e922 on aburgh:callback_performance into 2b82576 on nlohmann:master.

[nlohmann]

Thanks!!!

[nlohmann]

Hi @aburgh, I have another question... Sorry for bothering you again.

Do you have an idea how to cover theses lines with test cases:

• https://coveralls.io/builds/2525085/source?filename=src%2Fjson.hpp#L4644
• https://coveralls.io/builds/2525085/source?filename=src%2Fjson.hpp#L4713

All the best
Niels

[nlohmann]

Hi @aburgh, I have another issue related with performance:

When an object is parsed and the key is processed, the following code is executed:

// store key
expect(lexer::token_type::value_string);
const string_t key = m_lexer.get_string();

bool keep_tag = false;
if (keep)
{
    keep_tag = callback(depth, parse_event_t::key, basic_json(key));
}

Thereby, basic_json(key) constructs a temporary object which needs to be destructed afterward. This is not optimized away, yielding an overhead of one constructor/destructor per object entry. Do you have an idea how to improve this?

[aburgh]

Did you add test cases? I stepped through the unit tests and I see the tests in this section do provide code coverage:

        SECTION("filter specific events")
        {
            SECTION("first closing event")

[nlohmann]

They do. But I fail to cover the two lines I mentioned above.

[aburgh]

I'm confused about what Coverall reports as coverage. Those two lines of code are executed by the test that I referred to, I can see that in the debugger. Is executing the code not the definition of coverage?