Research: allocator, PGO, and build-level CPU levers (87.7 CPU-s gap)

[metaphorics]

Question

Which build/runtime-level levers plausibly cut whole-program CPU (gap: 87.7 CPU-s vs Core): allocator swap (mimalloc, jemalloc — measured expectations for allocation-heavy Rust), PGO for cargo (cargo-pgo, expected 5-15%?), BOLT, target-cpu=native vs the current baseline, codegen-units/LTO settings already in the release profile? Resolve current tool maturity, exact invocation for a cargo workspace, and realistic gain ranges from published measurements. Check what bitcoin-rs already sets in its release profile before recommending. Cite primary sources; note versions.

Part of #16.

[coderabbitai]

🔗 Related PRs

#14 - feat: header timestamp consensus rules, index reorg rollback, mempool policy, fuzz targets [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[metaphorics]

Resolution for Research: allocator, PGO, and build-level CPU levers (87.7 CPU-s gap): .outline/research/allocator-pgo-build-levers.md. Fat LTO and codegen-units=1 are already exhausted. The replay allocator differs from production and must be corrected for measurement parity. PGO is promising (unmeasured 8-18 CPU-s projection); BOLT is secondary (unmeasured 3-8 CPU-s projection).