Is there a performance bottleneck in this particular case?

[T-640]

When doing a quick search for a JSON library that best fits into my project I often observed people advising to use this library when convenience is the top priority and a few others when performance is critical. I assumed it is parsing of a JSON string or making one to send somewhere (over the network, for instance) is the subject of these talks about speed.

And while there is a certain part of my program where performance does matter, I, however, think this distinction between faster and slower JSON libraries may not apply to my particular case so I would like to find out whether my assumption is correct.

I practically use this library as a replacement for the std::unordered_map <std::string, std::any>. An empty nlohmann::json instance is constructed on the stack, may or may not be filled with some data and later is either discarded or copied. Those instances that were copied may be later saved to file if the user chooses to do so, but I suppose that performance there is irrelevant since the program already has to deal with the slow disk I/O anyway and I provide the user with a progress bar during the file opening/saving procedure.

So the only part where it matters to me in terms of performance is when this library is acting not as a JSON parser but as a mere substitute for the std::unordered_map <std::string, std::any>. Since no string parsing at all is done in that performance-sensitive part of the program and the primary purpose is to simply store some arbitrary values in memory I assume it does not matter whether a "fast" or "slow" JSON library is used in this case.

Am I thinking in the right direction?

[nlohmann]

The main difference should be in the internal implementation of the how the union of the value types is implemented. We use this (https://github.com/nlohmann/json/blob/develop/include/nlohmann/json.hpp#L423):

union json_value
{
    /// object (stored with pointer to save storage)
    object_t* object;
    /// array (stored with pointer to save storage)
    array_t* array;
    /// string (stored with pointer to save storage)
    string_t* string;
    /// binary (stored with pointer to save storage)
    binary_t* binary;
    /// boolean
    boolean_t boolean;
    /// number (integer)
    number_integer_t number_integer;
    /// number (unsigned integer)
    number_unsigned_t number_unsigned;
    /// number (floating-point)
    number_float_t number_float;
}

So there is overhead in dereferencing a pointer.