Further thoughts on performance improvements

[TurpentineDistillery]

My analysis of the performance bottlenecks showed that passthrough (non-instantiating) parsing performance is comparable to that of wc (i.e. near-perfect), and the major bottleneck is the usual bane of performant programming - mallocs and frees of many small objects. Can this be improved without resorting to custom allocators game? I think so. The performance becomes an issue when there are many json records to parse. In real-world scenarios the records will have the same schema - just the values that are different. Under this assumption, if we have an old json object that is no longer needed, it can be reused to update the values within, rather than let it expire, freeing the contents, and then allocate everything de-novo in a new json. This would entail having a function like json::parse(istream& istr, json& dest) that would take an existing record and reuse the existing fields where possible, making allocations only when necessary (longer strings, longer arrays, keys in maps that are absent in the old object, etc).

[TurpentineDistillery]

Another room for improvement:
Now we have operator[] accepting a key_type (string). This means that calls like j["foo"] necessitate creation of a string under the hood just to access the value. This could be avoided by adding overloads alongs the lines of

reference at(const char* const key)
{	
    static thread_local object_t::key_type k;
    k.assign(key);
    return at(key); // call the original `at`
}

Having said that, modern compilers use SBO-optimized std::string implementations, so the needless malloc/free churn when creating a temporary string occurs only in GCC<5, so this might be not worth the effort.

[nlohmann]

I recently (bd0326c, b1441f3, 0f04e42) started with some micro-optimizations using cachegrind to measure the number of executed instructions. This may not be a precise measurement that can be transferred to any architecture, but it helps to get a feeling where time is actually spent. Of course, wall-clock benchmarks are also required.

I shall continue focussing on the dump function. In particular, I want to move all related functions into a serializer class to recycled buffers and also the locale information.

(Sorry for hijacking this issue, but I did not find a better place to dump these thoughts)

[TurpentineDistillery]

This is precisely what the ticket was about, so you're not hijacking anything : )

Another place for optimization is unescaping unicode. Currently the code allocates a string for every character (not really a problem with SBO string implementations).

[TurpentineDistillery]

I tried adding an optimizing overload for string literals, but in both cases this results in ambiguous overload resolution : /

// prevent heap-allocating construction of a temporary string
// when accessing by string literal by reusing a thread_local storage.

#if 0
    const_reference operator[](const char* key const) const
#else
    template<int N> 
    const_reference operator[](const char (&key)[N]) const
#endif
    {
        static thread_local typename object_t::key_type s;
        s.assign(key);
        return (*this)[s];
    }

[theodelrieu]

You must add some enable_if to avoid the array-to -pointer decay, the parse method does exactly that ;)

[nlohmann]

I think the ideas here are realized by now.