Skip to content

[refactor measurement] Profile current-main Lean bottlenecks before selecting one candidate #4533

Description

@phasetr

Purpose

Establish new measured evidence on authoritative main before selecting any further build-speed or code-simplification refactor.

This issue is opened under the user's explicit instruction to continue refactoring. The separate 20-PR periodic-review gate has not been reached: only PRs #4522 and #4531 merged after the B1 implementation PR #4525. Explicit user authority satisfies the project gate to investigate, but it does not supply evidence for a code change.

Current-main anchor and existing evidence

Anchor: 71f79b0af982c819da0b749556122ddb211d3ebd.

Exact scope: measurement and candidate selection only

No Lean, TeX, documentation, import, proof, declaration, or generated-source edit is authorized by this issue.

  1. Before dynamic work, post a pre-registered measurement protocol anchored to the commit above. It must state the exact workload, commands, environment/toolchain fingerprint, cache policy, repetition count, rebuilt-module inventory, timing/RSS collection, warning capture, raw-evidence location, invalid-row rules, and rollback/selection threshold.
  2. Independently audit the current import/declaration DAG and consumers only to interpret the measured workload. Static chain length, LOC, or zero-reference text search is not sufficient selection evidence.
  3. Run the accepted protocol without committing source toggles or build artifacts; restore the exact source and prove a clean worktree after every row.
  4. Independently verify raw rows, medians, percentages, regenerated .olean inventory, warnings, RSS, source restoration, and commit identity.
  5. Select at most one smallest candidate only if the dynamic result identifies a concrete bottleneck and a fresh design audit demonstrates a stable abstraction/import boundary with real consumers. Record the proposed before/after boundary, supported public API, relevant workload, and numerical pass/rollback thresholds.
  6. Any selected code change requires a separate implementation-authority issue. If no candidate is justified, close this issue completed with a no-selection verdict.

Guardrails

This issue does not revive or authorize:

A previously declined category may be considered only if this issue produces genuinely new workload-specific measurement and the separate design audit explains why the old rejection no longer applies. It still requires its own implementation issue.

Acceptance criteria

  • Protocol is fixed before measurement and anchored to current main — Protocol-v11 fresh measurement at f61cd03b with exact registration/approval (§2, .self-local/reports/perf-4533-m0-bottleneck-2026-07-17.md)
  • Raw timing/RSS/warning/rebuilt-module evidence is retained and independently reproducible — .self-local/tmp/perf-fresh/rows.json (1992 rows: wall/real/user/sys + warning counts), run_all.py (runner), cp_fresh.py (weighted DAG), tail-unloaded-remeasure.txt (6-module unloaded tail, AC verified before/after); RSS = unsandboxed spot-check (5.5 GB, not retained in rows.json due to time -l sandbox limitation), honestly disclosed in checkbox 2
  • Every valid row proves exact source restoration and clean worktree — Measurement is read-only elaboration of unmodified sources; all scratch under gitignored .self-local/tmp/; final git status = clean (only pre-existing .self-local/issues/INDEX.md modified pre-measurement)
  • Static DAG/consumer evidence is tied to, but does not substitute for, dynamic measurements — §3.4 importer audit (1 direct consumer ClusterExpansion/StrictPositivity/TanhBounds.lean, set_option maxRecDepth/maxHeartbeats corroboration); §3.5 weighted import DAG with fresh node weights (cp_fresh.py): critical path = 734 s, throughput bound = 856 s, GraphCases off-path (own-chain 305 s)
  • Independent measurement and design reviews report zero unresolved findings — Round 1 (dev-review): F1–F6 (High/Med findings on v10-tainted data); Round 2: G1–G4 (Low/Med on fresh data); Round 3: R1–R3 (Low wording precision); Round 4: findings = 0; codex concurred all four rounds; NO-SELECTION re-derived independently by reviewer + codex
  • Outcome is either one minimal candidate specification for a separate issue or an explicit no-selection result — EXPLICIT NO-SELECTION (§4, .self-local/reports/perf-4533-m0-bottleneck-2026-07-17.md): distribution flat (median 3.89 s, p90 4.82 s); GraphCases sole outlier (65–115 s) off critical path with ~0.7–1.3% materiality (below gated-refactor bar); no implementation-authority issue created
  • No source/docs/generated artifact is committed under this issue — None (measurement read-only; all scratch in gitignored .self-local/tmp/)
  • No declined scope or Draft chore(benchmark): archive #4519 static evidence revisions 18–22 #4520 evidence is silently reused — All claims from fresh f61cd03b measurement; v10 (terminal INVALID, ref .self-local/reports/verify-4533-m0-v10-invalid-boundary-2026-07-16.md) demoted to non-load-bearing corroboration; no [benchmark] Measure incremental build impact of R1/R2/R5 #4519 Rev18–22, chore(benchmark): archive #4519 static evidence revisions 18–22 #4520, B0/B1 prior-evidence reused

Relationship

Follow-up investigation after completed #4506 and B1 #4524/#4525. This is the only active refactoring authority, and it authorizes evidence gathering and design selection—not implementation.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions