Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Version 0.4.0 #496

Merged
merged 35 commits into from Sep 10, 2022
Merged

Version 0.4.0 #496

merged 35 commits into from Sep 10, 2022

Conversation

lemmih
Copy link
Collaborator

@lemmih lemmih commented Jul 26, 2021

Changes:

  • The Criterion::can_plot function has been removed.
  • The Criterion::bench_function_over_inputs function has been removed.
  • The Criterion::bench_functions function has been removed.
  • The Criterion::bench function has been removed.
  • --feature csv_output is now required for csv output.
  • --feature html_reports is now required for html output.
  • Added a --discard-baseline flag.
  • rayon and plotters are optional (and default) dependencies.
  • Status messages ('warming up', 'analyzing', etc) are printed to stderr, benchmark results are printed to stdout.
  • Terminal escape codes are handled by the anes crate.
  • Accept subsecond durations as command-line options.
  • Formally support WASI (and automatically test for wasi regressions).
  • Add --quiet flag (for printing a single line per benchmark).
  • Replace serde_cbor with ciborium.
  • Upgrade to clap v3.
  • Bump regex to version 1.5.
  • Bump MSRV to 1.56.1.

lemmih and others added 4 commits July 26, 2021 15:16
* Disable warnings about HTML reports and standalone support.

* Include 'html_reports' in the set of stable features.

* Suppress html and csv if the feature flags are missing.

* Make the CSV dependency optional.

* Group optional dependencies in cargo manifest.

* Test both with all features and no features.
Some tools (e.g., rhysd/github-actions-benchmark) that parse the output of criterion do not correctly parse the standard output if it contains an unexpected string, such as an error message. The fix in this commit ensures that the tool will work correctly in environments where gnuplot is not installed (e.g., GitHub Actions runners).

Also, from the conventions of the command line interface, it is preferable that such error messages be output to stderr.
* Make the plotters dependency optional.

* Turn rayon into an optional dependency.

* Add cli flag for discarding baselines rather than saving them to disk.

* Disable plotting if html_reports is disabled.

* Support testing with and without the html_reports flag.
)

* Use terminal code to clear the line.

* Print status messages to stderr.
Status messages such as 'Warming up', 'Analyzing', etc.

* Use the 'anes' library for handling terminal escape codes.
* Accept subsecond durations from the command line.

* Replace 'to_nanos' with 'as_nanos'.
'as_nanos' stabilized in 1.33.
* Add --quiet flag. When enabled, only a single line is printed per benchmark.

* Print warnings and errors to stderr.
@@ -17,6 +17,7 @@ license = "Apache-2.0/MIT"
exclude = ["book/*"]

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be good to set version = "0.4.0" now.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would that make it easier for people to test this branch?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was easier for me to test with it left as-is, because I could use [patch.crates-io] to insert it into other dependencies like criterion-cycles-per-byte and pprof.

Cargo.toml Outdated
@@ -26,21 +27,24 @@ serde_derive = "1.0"
serde_cbor = "0.11"
atty = "0.2"
clap = { version = "2.33", default-features = false }

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My initial feedback: This branch with default-features=false and opting into no optional features is a drop-in replacement for 0.3.4 for me insofar as my benchmarks build and run using this version, simply with this change:

 [dev-dependencies]
-criterion = "0.3.5"
+criterion = { git = "https://github.com/bheisler/criterion.rs", branch = "version-0.4", commit = "7b8030b1223adacebf81b8e1cb3286a83e7a2470", default-features=false}

How practical would it be to move the anes, atty, clap, criterion-plot, and serde_cbor (at least) dependencies out of the "no default features" configuration?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's the cargo-tree of dependencies with default-features=false:

│   ├── anes v0.1.6
│   ├── atty v0.2.14
│   │   └── winapi v0.3.9
│   ├── cast v0.2.7
│   │   [build-dependencies]
│   │   └── rustc_version v0.4.0
│   │       └── semver v1.0.4
│   ├── clap v2.33.3
│   │   ├── bitflags v1.3.2
│   │   ├── textwrap v0.11.0
│   │   │   └── unicode-width v0.1.8
│   │   └── unicode-width v0.1.8
│   ├── criterion-plot v0.4.3 (https://github.com/bheisler/criterion.rs?branch=version-0.4#7b8030b1)
│   │   ├── cast v0.2.7 (*)
│   │   └── itertools v0.10.1
│   │       └── either v1.6.1
│   ├── itertools v0.10.1 (*)
│   ├── lazy_static v1.4.0
│   ├── num-traits v0.2.14
│   │   [build-dependencies]
│   │   └── autocfg v1.0.1
│   ├── oorandom v11.1.3
│   ├── regex v1.5.4
│   │   └── regex-syntax v0.6.25
│   ├── serde v1.0.128
│   ├── serde_cbor v0.11.2
│   │   ├── half v1.7.1
│   │   └── serde v1.0.128
│   ├── serde_derive v1.0.128 (proc-macro)
│   │   ├── proc-macro2 v1.0.28
│   │   │   └── unicode-xid v0.2.2
│   │   ├── quote v1.0.9
│   │   │   └── proc-macro2 v1.0.28 (*)
│   │   └── syn v1.0.75
│   │       ├── proc-macro2 v1.0.28 (*)
│   │       ├── quote v1.0.9 (*)
│   │       └── unicode-xid v0.2.2
│   ├── serde_json v1.0.66
│   │   ├── itoa v0.4.8
│   │   ├── ryu v1.0.5
│   │   └── serde v1.0.128
│   ├── tinytemplate v1.2.1
│   │   ├── serde v1.0.128
│   │   └── serde_json v1.0.66 (*)
│   └── walkdir v2.3.2
│       ├── same-file v1.0.6
│       │   └── winapi-util v0.1.5
│       │       └── winapi v0.3.9
│       ├── winapi v0.3.9
│       └── winapi-util v0.1.5 (*)

Some comments:

│   ├── cast v0.2.7
│   │   [build-dependencies]
│   │   └── rustc_version v0.4.0
│   │       └── semver v1.0.4

Not sure that cast is really carrying its weight considering the overhead it adds to the build. Either we could try to remove cast or we could work with the cast developers to simplify its build dependencies; I filed japaric/cast.rs#35 to that effect.

│   ├── clap v2.33.3
│   │   ├── bitflags v1.3.2
│   │   ├── textwrap v0.11.0
│   │   │   └── unicode-width v0.1.8
│   │   └── unicode-width v0.1.8

I don't fully understand how important clap::value_t is or how difficult it would be to replace, but I noticed if we could avoid using clap::value_t then we wouldn't need to depend on clap when the cargo-clippy feature isn't selected. So I think it is worth trying to find an alternative to value_t.

│   ├── serde v1.0.128
│   ├── serde_cbor v0.11.2
│   │   ├── half v1.7.1
│   │   └── serde v1.0.128
│   ├── serde_derive v1.0.128 (proc-macro)
│   │   ├── proc-macro2 v1.0.28
│   │   │   └── unicode-xid v0.2.2
│   │   ├── quote v1.0.9
│   │   │   └── proc-macro2 v1.0.28 (*)
│   │   └── syn v1.0.75
│   │       ├── proc-macro2 v1.0.28 (*)
│   │       ├── quote v1.0.9 (*)
│   │       └── unicode-xid v0.2.2
│   ├── serde_json v1.0.66
│   │   ├── itoa v0.4.8
│   │   ├── ryu v1.0.5
│   │   └── serde v1.0.128

Serde is a very heavy dependency. Granted, most of my projects use it anyway, so eliminating serde and serde-derive wouldn't have as wide an impact as removing other dependencies. However, I think finding a way to remove serde_cbor or serde_json (perhaps just default to one or the other) or both (In my CI jobs, I don't want any serializatoin at all since I don't do anything with serialized output; I just want to verify that the benchmarks still build and run) would be a good win.

│   └── walkdir v2.3.2
│       ├── same-file v1.0.6
│       │   └── winapi-util v0.1.5
│       │       └── winapi v0.3.9
│       ├── winapi v0.3.9
│       └── winapi-util v0.1.5 (*)

Again, in the pretty common situation where in CI where we're only verifying that the benchmarks compile and run correctly, and where we don't want any persistence anyway, we should be able to eliminate all the functionality that does file I/O and then eliminate this pretty heavy dependency.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be possible to make serde an optional dependency and have functionality degrade gracefully (ie. running/testing benchmarks should still work but saving/loading baselines would print an error message). I'll gladly review such a PR.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How practical would it be to move the anes, atty, clap, criterion-plot, and serde_cbor (at least) dependencies out of the "no default features" configuration?

criterion-plot is scheduled to be removed entirely (either in version 0.4 or 0.5). serde could be optional but it would take a fair bit of work/refactoring. I guess anes and atty could be optional but they're so tiny that I don't really see the point. clap is quite vital, though, and I don't see how criterion could work without it.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll gladly review such a PR.

OK, when I have time, I will try that. Will you be merging this PR (#496) soon? It would be easier for me to make my PRs on top of this one.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll gladly review such a PR.

OK, when I have time, I will try that. Will you be merging this PR (#496) soon? It would be easier for me to make my PRs on top of this one.

Probably won't be merged any time soon. You can submit your PR directly against this branch: Checkout version-0.4, push a new branch, and create a PR (or draft PR) with the target being version-0.4 from the drop-down menu.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had intended for command-line parsing and output and the like to start shifting over to cargo-criterion with the 0.4 release, so I think clap and anes and related crates should be behind the cargo-bench-support feature. That code would need to still be available in criterion-rs for the time being to give users time to migrate over to cargo-criterion (that's the purpose of the cargo-bench-support feature).

@briansmith
Copy link

With the PR as it is today, here is the effect on one of my projects:

+name = "anes"
-name = "bstr"
-name = "crossbeam-channel"
-name = "crossbeam-deque"
-name = "crossbeam-epoch"
-name = "crossbeam-utils"
-name = "csv"
-name = "csv-core"
-name = "memchr"
-name = "memoffset"
-name = "num_cpus"
-name = "plotters"
-name = "plotters-backend"
-name = "plotters-svg"
-name = "rayon"
-name = "rayon-core"
-name = "regex-automata"
-name = "scopeguard"

A net reduction of 16 dependencies.

@briansmith
Copy link

cast.rs 0.3.0 has been released with fewer dependencies.

@str4d
Copy link

str4d commented Dec 27, 2021

I tested db880ab on several of my projects, by adding the following patch:

[patch.crates-io]
criterion = { git = "https://github.com/bheisler/criterion.rs", rev = "db880abe2ff8b3c1c208d2e8ead4e21fbe1e05a4" }

No issues at all; it's a drop-in replacement and I didn't have to alter any code. Even the projects that use criterion-cycles-per-byte, or the criterion feature flag of pprof, continue to work fine.

I also confirmed (after removing criterion-cycles-per-byte and pprof integrations) that after replacing my criterion 0.3 dependency with a direct git revision and default-features = false, the benchmarks continued to compile and run, and I saw a similar drop in dependencies as above.

@str4d
Copy link

str4d commented Dec 27, 2021

#497 confuses me: it says that the cargo_bench_support feature flag is now honored, but all the PR does is remove the warning. cargo_bench_support has never done anything (it was added for forward-compatibility purposes), so the necessary logic still needs to be implemented.

I noticed this while looking into making serde optional: serde_cbor is a necessary component of cargo-criterion support, so a user like @briansmith who doesn't want serde therefore can't use cargo-criterion, and I guess would need to have cargo_bench_support enabled.

Since feature flags should always be additive, I think that implies we should also have a cargo_criterion_support feature flag, and then require that at least one of the two is enabled (otherwise there is no way to run benchmarks). I don't have the criterion repo knowledge to implement cargo_bench_support, but I'll look at adding cargo_criterion_support.

@str4d
Copy link

str4d commented Dec 27, 2021

Opened #541 to add cargo_criterion_support to this PR.

* Document WASM support with wasmer, wasmtime, nodejs, and browsers.
Cargo.toml Outdated Show resolved Hide resolved
@lemmih lemmih marked this pull request as ready for review July 2, 2022 14:49
@lemmih lemmih changed the title [WIP] Version 0.4.0 Version 0.4.0 Jul 2, 2022
@bheisler
Copy link
Owner

bheisler commented Jul 6, 2022

OK, so I've taken a look over this. Most of it looks great.

I'm a bit skeptical about the quick mode, but I could be convinced if people find it useful and reliable. If it's going to be added to criterion-rs support should also be added to cargo-criterion as well.

I'm a lot skeptical about vendoring critcmp, especially into this repo as opposed to cargo-criterion. Do we really want to take on the burden of maintaining and supporting critcmp at all? I suppose that we can use critcmp's source under its license, but BurntSushi seems to still be maintaining it and we'd presumably have to vendor in all of his changes forevermore. Additionally, one of my longer-term goals was to move as much functionality as practical out of criterion-rs and into cargo-criterion to reduce the compile- and link-time burden on running benchmarks. None of this is core to the process of doing the measurements, so it seems to fit better in cargo-criterion (whose job is storing and reporting the measurements) than it does here.

If we are going to add this feature, I'd rather work with BurntSushi to have just one copy of that code. Would he be open to providing it as a library crate we can pull in? Or, a hacky sort of solution, could we have cargo-criterion compare just shell out to critcmp instead of vendoring it?

Many of these changes should be made to cargo-criterion as well, like the changes to command-line output, but that doesn't need to block merging them into criterion-rs.

@lemmih
Copy link
Collaborator Author

lemmih commented Jul 8, 2022

BurntSushi doesn't want to maintain the code (neither as a library or as an executable). If we want the functionality to be part of the documented workflow for criterion then we have to maintain it ourselves. I'm volunteering to be responsible for it.

You're completely right that it doesn't belong in criterion.rs. How would you feel about me maintaining it as part of cargo-criterion? I think it's either that or we delete it and don't mention it in the documentation.

@bheisler
Copy link
Owner

Hm, I didn't realize it was abandoned.

One of the long-term problems I've had in maintaining Criterion-rs is that - since I haven't been writing (or benchmarking) much Rust code aside from sporadically maintaining Criterion - I don't really feel like I have a strong vision or opinion on how the workflow should evolve. Well, aside from introducing cargo-criterion to reduce compile- and link-time, as previously mentioned.

If you think critcmp is a worthy addition to that workflow, I'd be okay with merging it into cargo-criterion.

Copy link

@CosmicHorrorDev CosmicHorrorDev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a couple of things I noticed when working on #599

src/lib.rs Outdated
Comment on lines 805 to 806
.help("Limit the baselines used in tabulated results.")
.help(""))

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
.help("Limit the baselines used in tabulated results.")
.help(""))
.help("Limit the baselines used in tabulated results."))

src/lib.rs Outdated
};

let args = critcmp::app::Args {
baselines: matches.values_of_lossy("baselines").unwrap_or_default(),

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Parsing this causes a panic at runtime

thread 'main' panicked at 'Must use `Arg::allow_invalid_utf8` with `_os` lookups at `[hash: 570E2D9D9139F734]`', /.../cargo/registry/src/github.com-1ecc6299db9ec823/clap-3.2.12/src/parser/matches/arg_matches.rs:1732:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

This may be one of the errors that gets caught by debug_assert()

* Delete critcmp code (it belongs in cargo-criterion)

* Bump MSRV to 1.57 due to os_str_bytes.

* Mention MSRV bump in CHANGELOG.
@lemmih
Copy link
Collaborator Author

lemmih commented Aug 23, 2022

@bheisler I removed the critcmp code. Let me know if there's anything else we need to look at before 0.4 can be released.

@bheisler
Copy link
Owner

Only nice-to-haves, I think. I'll try and check over everything and hopefully publish 0.4.0 this weekend.

@bheisler
Copy link
Owner

bheisler commented Sep 6, 2022

Unfortunately a bunch of things came up and I was not able to get to it during the weekend, but I haven't forgotten.

@jhpratt
Copy link

jhpratt commented Sep 6, 2022

No worries! Things happen — I'm sure everyone can understand that.

@bheisler bheisler merged commit 935c632 into master Sep 10, 2022
@bheisler
Copy link
Owner

Thanks for your patience, everyone. I've merged and published 0.4.0.

@@ -425,4 +525,4 @@ more details
[0.3.3]: https://github.com/bheisler/criterion.rs/compare/0.3.2...0.3.3
[0.3.4]: https://github.com/bheisler/criterion.rs/compare/0.3.3...0.3.4
[0.3.5]: https://github.com/bheisler/criterion.rs/compare/0.3.4...0.3.5
[0.3.5]: https://github.com/bheisler/criterion.rs/compare/0.3.5...0.3.6
[0.3.5]: https://github.com/bheisler/criterion.rs/compare/0.3.5...0.3.6
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be [0.3.6]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet