Consider replacing serde-json with miniserde

[bheisler]

I try to keep Criterion.rs' dependency tree small. Serde-json brings a substantial number of dependencies and a lot of compile time. It's only used for basic persistence of state on cold code-paths so it might make sense to swap in a smaller, less-flexible implementation like miniserde. On the other hand, some fraction of Criterion.rs' users use serde themselves and so they wouldn't get any benefit from the change.

Of course, TinyTemplate would have to make the same switch.

[bheisler]

Unfortunately, miniserde does not yet support serializing enums, which is needed for Throughput. I'll revisit this if/when that's added.

I would also need to stop using csv's integration with serde, though that shouldn't be too hard.

[lemmih]

Is this still true? Looking at crates.io, serde-json only pulls in iota and ryu. miniserde also depends on those libraries.

[lemmih]

Here's a tree of all the serde related dependencies required by criterion:

├── serde v1.0.126
├── serde_cbor v0.11.1
│   ├── half v1.7.1
│   └── serde v1.0.126
├── serde_derive v1.0.126 (proc-macro)
│   ├── proc-macro2 v1.0.28 (*)
│   ├── quote v1.0.9 (*)
│   └── syn v1.0.74 (*)
├── serde_json v1.0.64
│   ├── itoa v0.4.7
│   ├── ryu v1.0.5
│   └── serde v1.0.126

Looks acceptable to me.

[bheisler]

serde-derive is the really heavy one, despite that it doesn't appear to have many dependencies. You're right that serde-json specifically isn't that heavy, but looking at the Criterion-rs compilation process with Cargo's profiling tools usually shows that the Serde system of crates is a major drag on our compile time. This is largely because it has to compile all of the procedural-macro machinery (serde-derive and all of its dependencies) before it can even start parsing Criterion-rs, which limits the parallelism available in the dependency graph.