Rain

The archive stuff often requires extra work within tests to enable, but that might be an okay tradeoff. (This is the sort of thing that should go into the design...

Thanks for the report! Huh, that's interesting -- how big are stdout and stderr for your tests? The default Linux x86_64 pipe size [is 65536 bytes](https://unix.stackexchange.com/a/11954). Regardless, 700ms+ just in...

To be honest, I can't reproduce this. With a Ryzen 7950x and Linux kernel 6.5.6 and Rust 1.73.0, with [this test](https://gist.github.com/sunshowers/85712961477ed07c6a241a8f3098402f) that writes roughly 500MiB, I get: * `cargo test`:...

I do see from `perf` that nextest is spending most of its time reading from the pipe, that's true. I also tried applying [this patch](https://gist.github.com/sunshowers/9f9be80aedbae176f8492eb90d636610) (Linux only) to make pipe...

Nextest uses a multithreaded runtime, and each test is its own task. However, reading from stdout and stderr are not split up into their own tasks.

Hi there, thanks for the report! I don't seem to be able to reproduce this issue with [datatest-stable](https://crates.io/crates/datatest-stable), with: * keeping libtest-mimic at 0.5.2 or bumping it to 0.6.0 *...

Ah thanks for the extended report. This is a bug in libtest-mimic.

I've proposed https://github.com/LukasKalbertodt/libtest-mimic/pull/30 in libtest-mimic which will fix this. For now, please avoid using `with_kind`.

> Somehow, cargo test must use a different test output collection strategy that's a lot more efficient. `cargo test` does its output collection in-process, without using OS pipes. That might...

This should be fixed with a libtest-mimic update. Thanks for the report!