Skip to content

perf(pm): add resolver manifest provider boundary#3030

Draft
elrrrrrrr wants to merge 4 commits into
nextfrom
perf/pm-split-resolver-provider-boundary
Draft

perf(pm): add resolver manifest provider boundary#3030
elrrrrrrr wants to merge 4 commits into
nextfrom
perf/pm-split-resolver-provider-boundary

Conversation

@elrrrrrrr
Copy link
Copy Markdown
Contributor

Summary

First review-sized split from #3028 / #2948.

Adds the manifest provider boundary used by the upcoming resolver main loop:

  • ManifestJob models full, version, and extract work units;
  • ManifestJobDone models completed provider work;
  • ManifestFullData separates full manifest payloads from cached versions.json data;
  • ManifestProvider keeps concrete I/O/parse/persistence work outside the BFS scheduler.

No behavior changes in this PR. It only introduces the typed boundary that later PRs will implement and consume.

Size

  • 2 files changed, 84 insertions(+)

Validation

  • cargo fmt
  • cargo check -p utoo-ruborist
  • cargo clippy --all-targets -- -D warnings --no-deps

pack-napi still warns locally because next.js is a symlink in this worktree; clippy exits successfully.

@elrrrrrrr elrrrrrrr added A-Pkg Manager Area: Package Manager benchmark Run pm-bench on PR labels May 21, 2026
Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces the ManifestProvider trait and associated enums (ManifestFullData, ManifestJob, ManifestJobDone) to abstract manifest resolution logic. This change separates I/O and parsing from the main BFS loop's scheduling and caching. A review comment suggests replacing a tuple in ManifestFullData with a named struct to enhance code clarity and maintainability.

Comment on lines +24 to +29
speculative: Option<(String, Arc<CoreVersionManifest>)>,
},
/// A validated versions list, usually from a 304 path. The main loop can
/// resolve a concrete version and schedule a version-manifest job.
Versions(Arc<VersionsInfo>),
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Using a tuple for speculative results can reduce code clarity and make it harder to extend in the future. Using a named struct explicitly defines the relationship between the spec and the manifest, improving maintainability and readability for other developers.

        speculative: Option<SpeculativeManifest>,
    },
    /// A validated versions list, usually from a 304 path. The main loop can
    /// resolve a concrete version and schedule a version-manifest job.
    Versions(Arc<VersionsInfo>),
}

/// Speculative extraction result.
#[derive(Clone)]
pub struct SpeculativeManifest {
    pub spec: String,
    pub manifest: Arc<CoreVersionManifest>,
}

@github-actions
Copy link
Copy Markdown

📊 pm-bench-phases · 3e18ac1 · linux (ubuntu-latest)

Workflow run — ant-design

PMs: utoo (this branch) · utoo-npm (latest published) · bun (latest)

npmjs.org

p0_full_cold

PM wall ±σ user sys RSS pgMinor
bun 9.21s 0.08s 10.45s 10.38s 652M 325.6K
utoo-next 8.28s 0.04s 10.62s 12.54s 955M 126.8K
utoo-npm 9.05s 0.81s 11.00s 13.03s 941M 123.9K
utoo 9.05s 0.97s 10.92s 12.96s 1007M 121.5K
PM vCtx iCtx netRX netTX cache node_mod lock
bun 17.2K 19.1K 1.19G 7M 1.86G 1.75G 1M
utoo-next 114.1K 85.8K 1.16G 5M 1.71G 1.70G 2M
utoo-npm 136.9K 98.8K 1.16G 5M 1.71G 1.70G 2M
utoo 142.2K 89.7K 1.16G 6M 1.71G 1.70G 2M

p1_resolve

PM wall ±σ user sys RSS pgMinor
bun 2.41s 0.06s 3.99s 1.13s 501M 191.5K
utoo-next 3.26s 0.03s 5.54s 1.89s 610M 82.6K
utoo-npm 3.41s 0.05s 5.72s 2.22s 611M 77.6K
utoo 4.43s 2.07s 5.49s 1.89s 609M 78.0K
PM vCtx iCtx netRX netTX cache node_mod lock
bun 12.2K 3.6K 202M 3M 107M - 1M
utoo-next 56.0K 75.8K 200M 3M 7M 3M 2M
utoo-npm 80.4K 92.2K 200M 3M 7M 3M 2M
utoo 54.9K 71.8K 200M 3M 7M 3M 2M

p3_cold_install

PM wall ±σ user sys RSS pgMinor
bun 6.85s 0.07s 6.37s 10.34s 573M 200.8K
utoo-next 10.12s 1.63s 5.25s 11.54s 536M 63.9K
utoo-npm 6.36s 0.14s 5.20s 11.10s 486M 59.8K
utoo 5.92s 0.37s 5.09s 10.73s 491M 64.7K
PM vCtx iCtx netRX netTX cache node_mod lock
bun 6.2K 8.2K 1019M 4M 1.76G 1.76G 1M
utoo-next 134.0K 50.2K 990M 4M 1.70G 1.70G 2M
utoo-npm 104.1K 50.0K 990M 3M 1.70G 1.70G 2M
utoo 86.0K 49.4K 989M 2M 1.70G 1.70G 2M

p4_warm_link

PM wall ±σ user sys RSS pgMinor
bun 3.29s 0.15s 0.20s 2.36s 135M 32.4K
utoo-next 2.33s 0.11s 0.48s 3.83s 79M 18.8K
utoo-npm 2.37s 0.02s 0.49s 3.80s 78M 18.0K
utoo 2.42s 0.12s 0.48s 3.80s 79M 17.9K
PM vCtx iCtx netRX netTX cache node_mod lock
bun 391 20 5M 46K 1.91G 1.75G 1M
utoo-next 41.5K 19.4K 25K 11K 1.70G 1.70G 2M
utoo-npm 39.2K 16.5K 25K 9K 1.70G 1.70G 2M
utoo 39.8K 18.2K 25K 11K 1.71G 1.70G 2M

npmmirror.com: no output captured.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-Pkg Manager Area: Package Manager benchmark Run pm-bench on PR

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant