Add ZipArchive metadata read benchmarks

[agocke]

Summary

• Add realistic ZipArchive metadata-reading benchmarks using a generated ZIP containing JSON package metadata and payload entries.
• Cover synchronous and asynchronous reads from both memory and file streams.
• Move the runtime-async feature gate to the repository root so BenchmarkDotNet-generated projects under artifacts/ inherit it.

The public async benchmark uses a synchronous BenchmarkDotNet entrypoint around a private async workload. This avoids BenchmarkDotNet generating an async void runner state machine while preserving runtime-async compilation for the measured workload.

Runtime comparison

Using matched compiler-async and runtime-async benchmark builds and System.IO.Compression CoreRoots:

Source	Compiler async	Runtime async	Time	Allocation
Memory	19.61 us, 29,568 B	18.56 us, 26,560 B	5.3% faster	10.2% less
File	424.71 us, 36,030 B	375.88 us, 33,044 B	11.5% faster	8.3% less

The results reproduced across two paired runs. The runtime-async benchmark workload contains no generated async state machine.

[Copilot]

Copilot review overview

🟢 Approval recommended

The changes look correct and aligned with the stated benchmarking/build goals, with only a minor benchmark-noise improvement suggested.

Review tier: Lite
Findings: 1

New issues introduced by this change (1)

Severity	Finding
	src/​benchmarks/​micro/​libraries/​System.IO.Compression/​ZipArchive.cs — GetMetadataEntry uses LINQ (Entries.First + predicate), which adds extra overhead/allocations into…

What changed in this PR

This pull request adds new microbenchmarks to measure ZipArchive metadata-reading performance across sync/async and memory/file-backed streams, and adjusts the build so the runtime-async feature gate is applied from the repository root (allowing BenchmarkDotNet-generated projects under artifacts/ to inherit it).

Changes:

• Added a ZipArchive metadata-reading benchmark that generates a representative ZIP (JSON metadata + payload entries) and measures sync vs async read paths from memory and file streams.
• Moved the runtime-async feature gating logic from src/Directory.Build.targets into the repository root Directory.Build.targets.
• Removed the now-unneeded src/Directory.Build.targets.

File	Description
src/​Directory.Build.targets	Removed subdirectory build targets so the root targets apply directly under src/.
src/​benchmarks/​micro/​libraries/​System.IO.Compression/​ZipArchive.cs	New microbenchmark for reading ZIP entry metadata (sync/async, memory/file).
Directory.Build.targets	Added root-level runtime-async feature gating so generated BDN projects under artifacts/ inherit it.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[timcassell]

This avoids BenchmarkDotNet generating an async void runner state machine while preserving runtime-async compilation for the measured workload.

What's the issue with async void calling async Task<int>? As far as I'm aware, the generated project should pick up the runtime-async feature from the root targets. And that generated code should result in better measurements than the GetAwaiter().GetResult() method.

The public async benchmark uses a synchronous BenchmarkDotNet entrypoint around a private async workload.

You can also use [ConsumeTasksSynchronously(true)] instead of manually wrapping it if you need that behavior.