# Size Evidence

This file records the current binary-size and code-size evidence for
`aria2-rust-pro` in Take 2 of the modernization goal.

## Commands

```powershell
rtk cargo build --release -p aria2-rust-pro-cli --manifest-path .\Cargo.toml -j $env:NUMBER_OF_PROCESSORS
rtk cargo bloat --release -p aria2-rust-pro-cli --bin aria2-rust-pro --crates -n 40 -j $env:NUMBER_OF_PROCESSORS
rtk cargo rustc --release -p aria2-rust-pro-cli --bin aria2-rust-pro --manifest-path .\Cargo.toml -- --emit=llvm-ir
rtk cargo llvm-lines --files target\release\deps\aria2_rust_pro.aria2_rust_pro_cli-d4c445ae209bfe38.aria2_rust_pro_cli.b493e489391677ca-cgu.0.rcgu.o.rcgu.ll
```

## Binary Size Snapshot

Measured on the current Windows host:

| Binary | Bytes | MiB |
| --- | ---: | ---: |
| `aria2-rust-pro.exe` | `5,213,184` | `4.97` |
| current C++ Pro Core `aria2c.exe` | `11,412,480` | `10.88` |
| upstream Windows `aria2c.exe` | `5,649,408` | `5.39` |

Observations:

- the current Rust binary is about `54.3%` smaller than the current C++ Pro Core
  artifact on this host
- the current Rust binary remains about `7.7%` smaller than the upstream
  Windows aria2 binary as well
- the latest reduction came from making the release profile more artifact-shaped:
  `codegen-units = 1`, `lto = "thin"`, and `strip = "symbols"`
- a later Phase 6 config-projection cleanup removed another small tranche by
  replacing repeated release-path `BTreeMap<String, String>` materialization
  with last-wins directive lookup on demand
- the latest checked tree, after the recent structural scheduler/DHT cleanup,
  leaves the release artifact at `5,213,184` bytes, up `28,672` bytes from the
  previous recorded snapshot rather than down
- the host artifact still stays below both checked C++ references

## Cargo Bloat Summary

Current top crate contributions from `cargo bloat --crates`:

| Crate | `.text` size |
| --- | ---: |
| `std` | `815.4 KiB` |
| `aria2_rust_pro_rpc` | `488.4 KiB` |
| `rustls` | `421.7 KiB` |
| `aria2_rust_pro_cli` | `246.7 KiB` |
| `aria2_rust_pro_protocol` | `236.3 KiB` |
| `reqwest` | `213.9 KiB` |
| `ring` | `124.2 KiB` |
| `hyper_util` | `107.8 KiB` |
| `hyper` | `104.2 KiB` |
| `aria2_rust_pro_core` | `100.6 KiB` |
| `tokio` | `94.4 KiB` |

Headline totals from the same run:

- `.text` section: about `3.6 MiB`
- file size from the bloat run: about `5.0 MiB`

Interpretation:

- the biggest owned size buckets are `aria2_rust_pro_rpc`,
  `aria2_rust_pro_protocol`, `aria2_rust_pro_cli`, and `aria2_rust_pro_core`
- the biggest third-party buckets are the HTTP/TLS stack:
  `reqwest`, `rustls`, `hyper`, `hyper_util`, `tokio`, and `ring`
- future size work should therefore focus on:
  - whether the default host binary really needs the full RPC/TLS surface in one
    always-on artifact
  - whether reqwest / rustls features can be trimmed without breaking the
    compatibility contract
  - whether any always-linked RPC/HTTP helpers can be split or made less eager
  - whether a future release flow should emit a stripped end-user artifact plus
    a separate debug-symbol artifact rather than making local release builds do
    both jobs at once
- within the owned CLI bucket, the same config-projection cleanup previously cut several
  previously ranked helpers materially in the filtered `cargo bloat` view:
  - `run_from_env`: `31.2 KiB` -> `30.2 KiB`
  - `projection::derive_http_session`: `8.6 KiB` -> `5.7 KiB`
  - `projection::derive_runtime_config`: `8.3 KiB` -> `4.0 KiB`
  - `build_ftp_transfer_parts`: `6.4 KiB` -> `3.9 KiB`

## LLVM Lines Snapshot

Direct `cargo llvm-lines --release -p aria2-rust-pro-cli --bin aria2-rust-pro`
currently fails on this Windows/MSVC host while linking the temporary
`cargo-llvm-lines` crate, with many unresolved external symbols. The project
itself still builds in release mode; the failure is limited to that tool's
temporary relink path.

The usable current workaround is:

1. emit release LLVM IR with `cargo rustc -- --emit=llvm-ir`
2. point `cargo llvm-lines --files` at the generated CLI `.ll` file

That current CLI crate IR snapshot reports:

- total: `53,272` LLVM IR lines across `307` function copies
- top entries:
  - `runtime_host::execute_run_invocation`: `5,538` lines
  - `run_from_env`: `4,380` lines
  - `parallel_http_runtime::execute_parallel_http_entries`: `3,751` lines
  - `http_runtime::execute_segment_transfers`: `2,364` lines
  - `http_runtime::execute_tagged_segment_transfers_with_parallelism`: `2,345`
    lines
  - `runtime_summary::collect_runtime_execution_summary`: `1,207` lines

Interpretation:

- the largest CLI-side IR buckets now line up with the Phase 6 runtime and HTTP
  transfer paths rather than a random unrelated module
- `parallel_http_runtime` remains a legitimate future split/size target, but it
  is also the path that just delivered the latest shared-runtime performance win
- full-workspace release LLVM-lines still needs a non-MSVC or fixed
  `cargo-llvm-lines` path before it should be treated as a strict gate

## Take 2 Reading

For Take 2, the honest conclusion is:

- size evidence now exists in-tree
- one real size-reduction tranche is now landed through the release profile
- the Rust host binary is now smaller than both the current C++ Pro Core and
  the upstream Windows binary checked on this host
- the main size pressure comes from the combined RPC + HTTP/TLS stack, not from
  one surprising internal crate explosion
- CLI-side LLVM IR now points at runtime execution and parallel HTTP scheduling
  as the next owned code-size targets
- the latest CLI IR refresh still confirms the earlier config-projection and
  shared-runtime cleanup reduced total CLI IR from `59,204` to `53,272` lines,
  but the newest structural tree should now be treated as synchronized mainly
  through the refreshed release build and `cargo bloat --crates` snapshot above
- deeper size reduction remains a future optimization lane, but the Phase 6
  evidence set is now current enough to rank that work honestly