cargo nextest list --list-type binaries-only appears to do a substantial amount of work that is not needed for its current behavior.

Today, the binaries-only path still eagerly:

• loads config and profile,
• parses filtersets and builds a TestFilter,
• initializes shared base state that includes Cargo metadata / PackageGraph setup, and
• in some cases resolves build platform metadata that is only needed for later phases.

However, the binaries-only branch ultimately just writes the BinaryList and does not use the profile or test filter.

Relevant code paths:

• cargo-nextest/src/dispatch/core/list.rs
• cargo-nextest/src/dispatch/core/base.rs

Measured on the nextest workspace itself, warm cache, macOS:

• cargo nextest list --list-type binaries-only: ~473 ms
• cargo nextest list --list-type binaries-only --cargo-metadata ...: ~330 ms
• cargo nextest list --list-type binaries-only --binaries-metadata ...: ~194 ms
• cargo nextest list --list-type binaries-only --cargo-metadata ... --binaries-metadata ...: ~52 ms

This suggests there is a meaningful win available from making the binaries-only path lazier:

• branch earlier in exec_list,
• skip config/profile/filterset construction for binaries-only while preserving current semantics, and
• defer cargo metadata / PackageGraph creation when reused binaries-metadata is already sufficient.

One open question is whether binaries-only should continue to ignore filtersets and profile-driven config. This issue is about preserving current behavior and avoiding dead work, not changing semantics.

Related:

• Reduce the binary size needed for build reusing #229
• Add filtering for packages, not just tests #154