sqlpp11 VS nativejson-benchmark

sqlpp11 actually helps in this area (which imo is the most error prone area of using a database) and offers compile time query checking

I haven't used this, though I did see some presentations about it which got my interest: https://github.com/rbock/sqlpp11

If you love C++ Template magic look at https://github.com/rbock/sqlpp11

This allows "normal" C++ code, which by the compiler is converted into the query string, allowing code like

    for (const auto& row : db(select(all_of(foo)).from(foo).where(foo.hasFun or foo.name == "joker")))

Well it would depend on the specifics of the JSON file but eyeballing the stats at https://github.com/miloyip/nativejson-benchmark/tree/master seems to indicate that even on a 2015 MacBook the parsing proceeds using e.g. Configuru parser at several megabytes per second.

Maybe you need to try some other third party json library and see if it helps. This is a good list https://github.com/miloyip/nativejson-benchmark

Glancing at some benchmarks, RapidJSON stringifies at around 250MB/s on a single core (content-dependent, of course). Does not look like a bottleneck.

How does it compare to the immensely popular JSON for Modern C++ library by nlohmann? https://github.com/nlohmann/json

Also, you should add your library to the JSON benchmarks here: https://github.com/miloyip/nativejson-benchmark#parsing-time

I like your ideas, but they seem difficult to enforce. It assumes good faith on all sides. One of the biggest complaints about AI/ML research results: It is frequently hard/impossible to replicate the results.

One idea: The edge competitors can create a public (SourceHut?) project that runs various daily tests against themselves. This would similar to JSON library benchmarks. [1] Then allow each competitors to continuously tweak there settings to accomplish the task in the shortest amount of time.

Also: It would be nice to see a cost analysis. For years, IBM's DB2 was insanely fast if you could afford to pay outrageous hardware, software license, and consulting costs. I'm not in the edge business, but I guess there are some operators where you can just pay a lot more and get better performance -- if you really need it.

[1] https://github.com/miloyip/nativejson-benchmark

There's some useful benchmarks here. I found it while looking for stats on json-c vs parson, which I've used a fair amount.

If you looking for benchmarks to show in which cases your library is better than other 30 or so competitors, then see this repo https://github.com/miloyip/nativejson-benchmark

JSON data files from this project: https://github.com/miloyip/nativejson-benchmark

Such a shame, really. There is a ton fast json parsers there, like https://github.com/miloyip/nativejson-benchmark#parsing-time. And second issue is just hilarious: let's scan array millions of times, who needs hashmaps anyway?