Minimal toml configuration could compile more quickly

[hanna-kruppe]

Context: I'm currently using toml-span as dev-dependency for parsing files in a data-driven test harness, not entirely unlike trycmd's TOML files. The schema is very simple and all files are authored by developers, so the bugs in toml-spec aren't a serious concern for that use case.

I've previously picked toml-span over toml 0.8 for this because of compile times and because it didn't pull in serde. Now that toml 0.9 supports a configuration ("parse" feature only) that's closer to toml-span in terms of scope, compile time, and dependency tree, I'm looking into switching to the more popular, correct, and maintained library.

Unfortunately toml-span 0.5.2 still compiles faster than toml 0.9.5. This is not necessarily a blocker, but I'd like to highlight it in case it can be fixed without too much trouble. As a self-contained example, for a hello world binary that depends on nothing else but toml (parse only) or toml-span respectively, the former takes ca. 2x longer to compile in dev profile:

$ cargo new test-build-toml && cd test-build-toml/
$ cargo add toml@0.9.5 --no-default-features -F parse
$ hyperfine -w2 'cargo build -j1' --prepare 'cargo clean'
Benchmark 1: cargo build -j1
  Time (mean ± σ):      2.440 s ±  0.048 s    [User: 2.037 s, System: 0.277 s]
  Range (min … max):    2.380 s …  2.539 s    10 runs

$ hyperfine -w2 'cargo build' --prepare 'cargo clean'
Benchmark 1: cargo build
  Time (mean ± σ):      1.784 s ±  0.028 s    [User: 2.279 s, System: 0.281 s]
  Range (min … max):    1.756 s …  1.849 s    10 runs

$ cargo remove toml && cargo add toml-span@0.5.2
$ hyperfine -w2 'cargo build ' --prepare 'cargo clean'
Benchmark 1: cargo build
  Time (mean ± σ):     810.5 ms ±  19.8 ms    [User: 1039.5 ms, System: 176.7 ms]
  Range (min … max):   787.2 ms … 840.8 ms    10 runs

$ hyperfine -w2 'cargo build -j1 ' --prepare 'cargo clean'
Benchmark 1: cargo build -j1
  Time (mean ± σ):      1.148 s ±  0.016 s    [User: 0.888 s, System: 0.147 s]
  Range (min … max):    1.123 s …  1.172 s    10 runs

This appears to be entirely due to using winnow: it accounts for 1.3sec of the build time on my machine. I wouldn't question this if the toml crates were still written with parser combinators. But from a quick survey, it seems that only a few bits and pieces from winnow::stream are used, amounting to a tiny fraction of winnow. I've not looked into every single usage but most of them seem either trivial to avoid entirely (e.g., AsBStr in this context only provides a different name for str::as_bytes) or not too hard to extract into something free-standing (e.g., substring search with optional use of memchr).

How would you feel about a PR that removes and/or extracts those bits and pieces so the toml crates don't need to depend on winnow at all?

[epage]

I had considered it at the time because it is small pieces I'm using but I still want to use some of those tools (like next_token, etc) and do not feel like maintaining a fork of that subset. I am surprised at how slow winnow is to compile and wonder if that could be improved.

[hanna-kruppe]

I haven't looked into that (yet) so maybe there's some low hanging fruit. But from where I stand now it seems more like winnow is just a lot code for the compiler to go through. Naively running tokei over winnow's src/ reports 27k LOC, while toml_parser is 8k and toml is 12k (and toml probably has a lot more things cfg'd out than winnow in this experiment). But adding very fine grained features to winnow so the toml crates only pay for what they need doesn't sound very fun, either.

[hanna-kruppe]

There's also a fair amount of macro-generated code in winnow. cargo +nightly rustc -p winnow -- -Zmacro-stats starts with:

macro-stats ===================================================================================
macro-stats MACRO EXPANSION STATS: winnow
macro-stats Macro Name                         Uses      Lines  Avg Lines      Bytes  Avg Bytes
macro-stats -----------------------------------------------------------------------------------
macro-stats permutation_trait_inner!            250      2_750       11.0     89_592      358.4
macro-stats alt_trait_inner!                    230      2_410       10.5     64_604      280.9
macro-stats succ!                               440        680        1.5     37_818       86.0
macro-stats permutation_trait_impl!              20        738       36.9     34_962    1_748.1
macro-stats impl_contains_token_for_tuple!       21        491       23.4     29_612    1_410.1
macro-stats impl_parser_for_tuple!               22        617       28.0     27_786    1_263.0
macro-stats alt_trait_impl!                      20        371       18.6     18_607      930.4
macro-stats impl_parser_for_tuples!              23        137        6.0      8_869      385.6
macro-stats permutation_trait!                   21        128        6.1      8_303      395.4

[epage]

I've created winnow-rs/winnow#809 to track the winnow side of this.

Out of curiosity, I did some comparisons on my system

$ cd toml
$ cargo clean && time cargo build -p toml --no-default-features -F parse
real    0m1.187s
user    0m1.658s
sys     0m0.345s
$ git checkout toml-v0.5.11
$ cargo clean && time cargo build -p toml
real    0m2.365s
user    0m6.027s
sys     0m0.416s
$ cd ../toml-span
$ cargo clean && time cargo build -p toml-span
real    0m0.544s
user    0m0.808s
sys     0m0.182s
$ cd ../basic-toml
$ cargo clean && time cargo build -p basic-toml
real    0m1.951s
user    0m1.607s
sys     0m0.260s

Looking at timings