Only use yaml from config

[CosmicHorrorDev]

I compile this program from the AUR on my pretty weak laptop so I wanted to see if I could slim down compile times a bit. It looks like the only format used from config is yaml and restricting it to that gets single job debug compile times from a total of 226.72s to 201.65s and release times from 673s to 603s on a Ryzen 5 1600.

[Nukesor]

Nice!

Thanks for the contribution. 10% speedup in compile time is pretty significant 👍

[Nukesor]

I really like the idea of reducing compile time :D

Hence, I just released a new version of comfy-table, which reduces the compile time from 10.7 to 6.5 for that dependency, which is around ~40% in Comfy-table.

On top of that, async-timers has been removed and replaced by native async-std timers. This reduces the compile time from 39.1 to 34 sec, which is ~13%.

After these changes, we're down from 39.1 to 31, which is ~21%.

I'll check if there are some other dependencies that can be removed.

[CosmicHorrorDev]

Well, I just opened a PR with rust-skeptic to replace tempdir since that was causing a duplicate here from comfy-table, but it looks like that's no longer an issue! cargo tree --duplicates is picking up some duplicates caused by different version so it might be worth looking into those.

[CosmicHorrorDev]

The different strum_macros and strum versions are likely the easiest fixes. I'll look into the others either later tonight or tomorrow.

[Nukesor]

Well, I forgot to update all dependencies before releasing Comfy-Table v1.1.
I just released a patch with strum and strum_macros updated to v0.19. That's another duplicate dependency removed.

However, this didn't change much in terms of compile time. Looks like strum is too small to make a significant impact.

[CosmicHorrorDev]

I'll be looking around more when I have the time, but I haven't found any easy wins yet since tt looks like everything left is already doing a non-trivial amount of work. I had a decent amount of hope in handlebars since it brings in quite a few unique dependencies that take up a decent amount of the total time, but all the dependency light alternatives I looked at seem to pull in basically the same dependency tree one way or another.

It is already compiling significantly faster for me now so I'm really glad that you helped out where you could too ❤️ (clean release build is down to 4m 43s on my laptop)

These are the results of debug and optimized times from cargo bloat -j 1 --time and cargo bloat -j 1 --time --release just for reference (compiled on a Ryzen 5 1600 running linux since it matters for which dependencies are pulled in, one job because that seems to be the most system generic way of expressing times).

Debug (Total 156s)

  Time Crate
11.12s syn
 7.30s clap
 7.21s async_std
 6.79s serde_derive
 6.75s pueued
 6.42s procfs
 6.06s nix
 5.85s serde
 5.62s pueue
 5.25s handlebars
 4.71s pueue
 3.07s pest_meta
 2.71s nom
 2.57s libc
 2.39s structopt_derive
 2.39s serde_json
 2.20s lexical_core
 2.17s crossterm
 2.00s strum_macros
 2.00s yaml_rust
 1.91s chrono
 1.88s proc_macro2
 1.81s config
 1.69s libflate
 1.67s serde_yaml
 1.43s rand
 1.39s pest_generator
 1.38s pest
 1.27s snap
 1.27s async_io
 1.20s users
 1.17s num_traits
 1.15s comfy_table
 1.00s log
 ... (Cutoff any below 1s)

Release (Total 423s)

  Time Crate
45.96s syn
29.28s serde_derive
23.45s clap
22.37s procfs
22.07s pueued
18.98s handlebars
17.84s async_std
16.18s pueue
15.41s strum_macros
14.78s structopt_derive
12.70s pueue
10.68s pest_meta
 8.84s nix
 7.64s pest_generator
 7.31s config
 6.70s serde
 6.09s yaml_rust
 5.69s proc_macro2
 5.33s serde_json
 5.07s serde_yaml
 5.04s async_attributes
 4.68s crossterm
 4.18s libc
 4.15s chrono
 3.69s comfy_table
 3.66s libflate
 3.55s async_io
 3.33s nom
 2.96s users
 2.57s snap
 2.55s proc_macro_error_attr
 2.54s rand
 2.42s lexical_core
 2.41s proc_macro_error
 2.39s quote
 2.34s autocfg
 2.23s simplelog
 2.21s signal_hook
 2.08s version_check
 2.03s pest
 2.00s time
... (Cutoff any below 2s)

[Nukesor]

I thought about replacing Handlebars as well, since it's a really heavy duty and super feature-rich library.
However, I couldn't find anything that satisfied my requirements, while being properly maintained :D.

Anyway, I'm really happy with the results. This was actually quite fun :D.
In your case, going down from 673s to 423s already seems like a huge achievement to me :).

Thanks again for helping out 👍