nativejson-benchmark VS js-compute-runtime

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?

There are multiple JavaScript runtimes. SpiderMonkey is one example that has nothing to do with Node.js, see (js-compute-runtime)[https://github.com/fastly/js-compute-runtime].

We listened to the community feedback, filled in feature gaps, and addressed many bugs in the SDK. Not only that, we’ve also overhauled the SDK reference docs making it easier for you to know what’s supported and how to implement the features. All the Fastly specific features of the JS SDK now have interactive example applications in the documentation.

These are good questions! Here's some answers from the corner of the world I know best as a Wasmtime contributor at Fastly:

1. Spidermonkey.wasm is the basis of Fastly's JavaScript on Compute@Edge support. We have found it to be faster than QuickJS. The source code is here: https://github.com/fastly/js-compute-runtime.

2. Fastly Compute@Edge is built on wasmtime. You can develop web services for it in Rust, JS, and Go: https://developer.fastly.com/learning/compute/

3. Fastly's multi-tenant platform is closed source, but our single-tenant local development platform, which also uses wasmtime under the hood as well, is open source: https://github.com/fastly/viceroy. It isn't a big leap to make viceroy multi-tenant: Wasmtime provides everything you need, and all Viceroy would have to do is dispatch on e.g. HTTP host header to the correct tenant. Our multi-tenant platform is closed source because it is very specialized for use on Fastly's edge, not because the multi-tenant aspect is special.

btw. for what it's worth their javascript to wasm is opensource:

- https://github.com/fastly/js-compute-runtime

- https://github.com/tschneidereit/spidermonkey-wasi-embedding

and besides that it is slower than nodejs it is still plenty fast (no matter that it is not as fast as they want) btw. it's startup is faster than node. (maybe better pgo might help)