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

Fix performance regression introduced with the parsing callback feature. #69

Merged
merged 1 commit into from
May 4, 2015

Conversation

aburgh
Copy link
Contributor

@aburgh aburgh commented May 4, 2015

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
Copy link

Coverage Status

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

nlohmann added a commit that referenced this pull request May 4, 2015
Fix performance regression introduced with the parsing callback feature.
@nlohmann nlohmann merged commit 723155a into nlohmann:master May 4, 2015
@nlohmann
Copy link
Owner

nlohmann commented May 4, 2015

Thanks!!!

nlohmann added a commit that referenced this pull request May 4, 2015
@nlohmann
Copy link
Owner

nlohmann commented May 9, 2015

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

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

All the best
Niels

@nlohmann
Copy link
Owner

nlohmann commented May 9, 2015

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 aburgh deleted the callback_performance branch May 10, 2015 21:47
@aburgh
Copy link
Contributor Author

aburgh commented May 10, 2015

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
Copy link
Owner

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

@aburgh
Copy link
Contributor Author

aburgh commented May 11, 2015

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants