Creating on the fly json objects

[GJanos]

In my current assignment, I would like to construct JSON objects on the fly for logging purposes. It would be necessary so that I can log anything and everything without much effort or just for debugging purposes.
Performance is really important in my case so I choose glaze as my ser/deserialization/json creation library.
When creating a json object like this:

glz::json_t json = {
    {"pi", 3.141},
    {"happy", true},
    {"name", "Stephen"},
    {"nothing", nullptr},
    {"answer", {{"everything", 42.0}}},
    {"list", {1.0, 0.0, 2.0}},
    {"object", {
        {"currency", "USD"},
        {"value", 42.99}
        }
    }
};

It is said in the description of the "If absolutely nothing is known about the JSON structure, then [glz::json_t] may be helpful, but it comes at a hefty performance cost due to the heavy use of dynamic memory allocations." Indeed, after testing it out, this approached seemed slower than a purely stack memory allocated libraries solution (boost::json::value). I know it is not fair to compare these 2 options, but that is why I wrote this.

Is there a way for me to construct glaze::json objects faster and with less memory allocations? Could the smaller object be purely stack allocated and for bigger objects maybe pre-allocated heap could be a solution. If a solution already exists, please give me a short example.

Thank you for your time!

[stephenberry]

Thanks for bringing up your specific problem. The best solution, as you say, would be to stack allocate these objects. The glz::json_t uses a std::unordered_map, which is more expensive for your logging purpose.

What we probably want to support is the ability to use glz::object tuples directly. For example:

auto obj = glz::object("pi", 3.141, "happy", true, "name", "Stephen");
std::string s{};
glz::write_json(obj, s);

We aren't far from supporting this, but I'm not sure when I'll be able to add this feature. However, your request has put this on my radar and I do think it is worthwhile. It would make logging extremely efficient without needing to write glz::meta structures.

Thanks for your feedback, sorry we don't have an immediate solution. But, I will turn this into an issue to address.

[GJanos]

Thank you for your fast and kind response, and for the detailed explanation! I am happy to hear that this question got into your radar! Hope it gets added soon! Wish you the best of luck!

[stephenberry]

Feature has been added, see #303

[GJanos]

Dear stephenberry!
First of all, thank you again for reacting to my discussion so fast and adding a feature to support it. I have tried to work with it and have a few points, that I would like to ask and clarify.

If I created an object like this:

glz::obj{"pi", 3.141, "happy", true, "name", "Stephen", "arr", glz::arr{"Hello", "World", 2}});

I believe there would be no dynamic memory allocations (I am not sure, only tested the performance, but like this it was significantly faster).

Although on the other hand, if I created the object like this:

std::vector<int> vec = {1, 2, 3};
std::map<std::string, int> map = {{"a", 1},{"b", 2},{"c", 3}};
glz::obj{"pi", 3.141, "happy", true, "name", "Stephen", "arr", glz::arr{"Hello", "World", 2},
                               "map", map,
                               "vector", vec};

The performance plummeted. ( but it might just be due to the object being larger itself...)
Do you support the glz::map type in glz as well, or just the glz::array? I was not able to find it, but it would be a great addition, if not already added yet. ect:

glz::obj{"pi", 3.141, "happy", true, "name", "Stephen", "arr", glz::arr{"Hello", "World", 2},
                               "map", glz::map{{"a", 1},{"b", 2},{"c", 3}}};

Other difficulty arise when I tried to pass the glz::obj as a function parameter. Because of its variadic template definition it gets really hard to pass that object around between functions.

template <typename... Args>
  static std::string serialize_data(glz::obj<Args...> const &data)
  {
      return glz::write_json(data);
  }

Could you somehow change this type or maybe put a wrapper class/struct around it that might make it easier to use?

Thank you for your time, looking forward to your answer!

[stephenberry]

@GJanos
I can add this behavior, and will try to do so soon.

[GJanos]

@stephenberry
Thank you! Let me know when that feature is ready ! :)

[stephenberry]

@GJanos,
The latest merges (#341 & #342) should solve your problems. glz::merge now works with other JSON object-like types. Also, glz::merge can now take rvalue references for cleaner syntax. And, glz::arr and glz::obj also avoid copies when passed lvalues, so performance should be better in some cases.

[GJanos]

Dear @stephenberry !

I made a small demo code that explains one of my problems. When I run this, instead of incrementing numbers getting printed, I only get 10 10 times.

#include <vector>
#include <glaze/glaze.hpp>
#include <fmt/core.h>

int main() {
    int cnt = 0;
    glz::obj o{"count", cnt};
    std::vector<decltype(o)> vec;
    for (cnt = 0; cnt < 10; ++cnt) {
        vec.emplace_back(glz::obj{"cnt", cnt});
    }
    for( const auto& i: vec ) {
        fmt::print("count value:{}\n", glz::tuplet::get<1>(i.value));
    }
}

Log output: 10 pieces of 10. No incrementing numbers, because of the glz::obj taking the cnt value as a const int&.

Glz::obj taking references indeed improve performance, but sometimes occasional deep-copies are needed. Especially when a glz::obj would want to be logged, so it would get copied and the copy would be put to a backend threads spnc queue for later work. But because of a shallow-copy getting made, the values of the object inside of the queue would get corrupted.

For this reason it would be an awesome feature to be able to customize the glz::obj and maybe even your own types (but currently glz::obj is the priority) whether you want them shallow or deep-copied.

Glaze already supports something like:

glz::write<glz::opts{.prettify = true}>(obj, buffer);
So, applying this to glz::obj would be something like:
glz::obj<glz::opts{.deep_copy = true}>

Extra boolean template, or some other solution. And default could be the shallow copy option. This could be a object lvl setting or maybe an attribute lvl option.

template<>
struct glz::meta<Trade_data> {
    using T = Trade_data;
    static constexpr auto value = glz::object(
            "id", &T::id, "shallow",
            "name", &T::name, "deep",
            "price", &T::price, "shallow",
            "quantity", &T::quantity, "shallow",
            "exchange_name", &T::exchange_name, "deep") ;
};

And based on the template parameter call deep or shallow copy constructor on the attributes of the class.

Basically I would need a way to deep copy glz::obj on the stack. Not with moving the data or references.

[stephenberry]

@GJanos

I'll address your simple example. If you specify copies when you constructor your glz::obj, then you can solve this demo problem as follows:

size_t cnt = 0;
glz::obj o{"count", size_t{cnt}};
std::vector<std::decay_t<decltype(o)>> vec;
for (; cnt < 10; ++cnt) {
   vec.emplace_back(glz::obj{"count", size_t{cnt}});
}
for (size_t i = 0; i < vec.size(); ++i) {
   expect(i == glz::tuplet::get<1>(vec[i].value));
}

This all works as expected because the counts are all copies as you want them. This may also work for your larger problem. If it doesn't, let me know and we can discuss the particular problem.
With glz::obj taking references I like the fact that copies must be explicitly defined by the user, so it is more obvious where there can be performance bottlenecks.

Also, note my added std::decay_t to the object type stored in the vector. This is needed to avoid taking references.

[GJanos]

Dear @stephenberry !

I have found a possible bug. When I have a std::string containing a json, and I would like to convert that to a glz supported object, so later on I could merge that object with an another. I did not find any easy way to achieve this.
I wanted something like:

glz::obj temp = glz::parse_json_str(string_json);

//found this approach
glz::json_t j;
glz::read_json(j,string_json);

This worked, however, when I tried to std::merge glz::obj and glz::json_t object (where the glz::json_t contained a MAP) parsing problems happened. This could be due to glz::obj not handling map types. But would be nice it these 2 types could be merged together easily OR make a glz::parse_json_str like function that immediately makes a glz::obj, and handles map types inside the string as well.

Made a small demo that illustrates the problem:

int main() {
    glz::obj o {"not", "important"};
    glz::obj o2 {"map", glz::obj{"a", 1, "b", 2, "c", 3}};
    std::string s = "{\"key1\":42,\"key2\":\"hello world\",\"map\":\"key\",\"v\":[1,2,3],\"m\":{\"a\":1,\"b\":2,\"c\":3}}";
    glz::json_t j;
    glz::read_json(j,s);
    auto test1 = glz::write_json(j);
    auto merged = glz::merge{o, j};
    auto test2 = glz::write_json(merged);
    auto merged2 = glz::merge{o, o2};
    auto test3 = glz::write_json(merged2);
    fmt::print("{}\n", test1);
    fmt::print("{}\n", test2);
    fmt::print("{}\n", test3);
//    {"key1":42,"key2":"hello world","m":{"a":1,"b":2,"c":3},"map":"key","v":[1,2,3]}
//    {"not":"important","key1":42,"key2":"hello world","m":"a":1,"b":2,"c":3,"map":"key","v":[1,2,3]}
//    {"not":"important","map":{"a":1,"b":2,"c":3}
}

Thank you for reading my message, I am looking forward to your reply for this and my previous comment.

[stephenberry]

@GJanos
Thanks for pointing this out. There was a problem with nested objects within glz::obj. This has now been fixed (#349). I think this should solve your problem, but I do want to add reading directly into glz::obj in the future.