Can you share your local benchmark results?

I didn't post it because the benchmark was too flaky, but there you go.

Can you try profiling from your PC?

swc_malloc is a utility crate that configures global malloc with the best one for each platform.

Do you have any information that backs up that "best" claim for reference?

Presently it looks like swc_malloc only has two allocators that'd be selected? mimalloc and jemalloc (Cargo.toml + conditionals for each in lib.rs).

You use mimalloc for anything not on linux, and jemalloc for linux (but only x86_64 + aarch64 archs on -gnu target), anything else will fall back to the default? So that will not be the best for -musl targets which tend to perform poorly (especially on multi-threaded contexts) with the default allocator.

You may want to evaluate snmalloc which may be worthwhile.

Keep in mind that the most appropriate allocator choice really depends on the workload context.

• So pushing swc_malloc elsewhere may not make the "best" allocator choice for other projects, the effectiveness could vary on which one is actually best for a projects needs?
• Given the prefix, would it be safe to say that the choice of allocator is subject to change, will it be a breaking semver change or implicitly forced upon downstreams where regressions may occur?

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.30%. Comparing base (71bf423) to head (395a9d2).

@@            Coverage Diff             @@
##             main     #188      +/-   ##
==========================================
- Coverage   89.38%   89.30%   -0.08%     
==========================================
  Files          61       61              
  Lines        5313     5313              
==========================================
- Hits         4749     4745       -4     
- Misses        564      568       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Feel free to inline it if you want

As @kdy1 does not seem interested in responding to the raised concerns, it is probably not worthwhile merging the PR.

• Claims of allocator selection being best lack evidence / context and may not be applicable to other projects. No clear advantage demonstrated for paquet?
• Allocator selection excludes either for -musl targets, using the default which performs poorly in multi-threading.
• Allocator selection may be subject to change implicitly, neither is explicit selection control available.

Sorry, I'm too lazy to explain it to you.

If you want description, see the git history of the crate.

It's recently renamed, so you may need to use github UI or you should have a bit of git skills.

If you want description, see the git history of the crate.

I did, the original crate introduced the allocator here with both jemalloc and mimalloc (specific commit from PR branch).

Like with other commits and PRs related to the allocator history, there is very little information beyond some bench result snippets shared in PRs. These provide minimal context and instill no confidence in addressing the concerns I raised about merging your PR here.

I'm too lazy to explain it to you.

Being lazy to respond to these questions is ok 👍 But by not doing it should discourage @KSXGitHub from approving this PR.

• You're aware that just because you had an improvement in your bench, it does not mean it will be "best" for all projects? All you have to support your choice is a few lines of benches related to your project?
• You're aware that your crates config patterns is non-exhaustive? The common musl targets are excluded intentionally (without any reasoning?)
• You're aware that you may change the allocators in future, or adjust which targets qualify for a specific allocator, yet won't express if that'd be treated as a breaking change semver bump, or if you'd provide any explicit control of allocator selection?

You are promoting adoption of something unreliable, with very little evidence to support it. @KSXGitHub would be better off explicitly managing the global allocator themselves (should they see value in switching the allocator wholesale, or configuring multiple based on target).

xxx_malloc crate is important for multi-crate projects because you can do extern crate xxx_malloc from benchmark files. It does not replace the default malloc if there's no extern crate. If you try to inline it into a final binary crate, configuring malloc for benchmarking becomes very cumbersome.

#[cfg.target(xxx).dependencies]

in Cargo.toml of each crate is required.

One more problem is that, over time the build breaks. That's why I simply use swc_malloc (formerly swc_node_base) from my other private projects. I'll maintain SWC anyway - so I don't need to update my side project just because of the build environment change.

About musl, those are excluded because musl builds are very slow in GitHub action.

Sorry for being rude. I had too many tasks at that time.

Rebased this onto current main (71bf423) so CI + benchmarks can actually run against today's code.

The original 2023-11 commit (e001251) was two years off from the current workspace — Cargo.toml had shifted substantially and the rebase hit conflicts on both Cargo.toml and Cargo.lock. Rather than resolve conflicts line-by-line for a three-file diff, I cherry-picked the essence onto a fresh commit (395a9d2) authored by me with Co-authored-by: @kdy1 for attribution, bumped swc_malloc from the original pin to the current 1.2.5, and fleshed out the rationale with an inline comment at the extern crate site.

Substantively identical to the original change:

• swc_malloc = "1.2.5" added to workspace deps
• Crate listed as a dep of pacquet-cli
• extern crate swc_malloc; at the top of crates/cli/src/lib.rs (activates the crate's embedded #[global_allocator] — mimalloc on macOS/Windows, jemalloc on Linux)

Local just ready passes (205/205). Waiting on integrated-benchmark to measure the payoff against main.

First CI bench came back with swc_malloc 2% slower than main on the Linux runner — 57 ms gap, inside noise bands (ratio 1.02 ± 0.04), and consistent with the 1-2% "second-listed command wins" ordering bias we measured separately on #278. Real allocator difference: statistically indistinguishable from zero.

The likely reason: swc_malloc picks jemalloc on Linux, and modern glibc (Ubuntu 24.04 runners ship glibc 2.39) has narrowed the gap to jemalloc substantially. The old "jemalloc is 10-20% faster than glibc" benchmarks are from glibc 2.31-era. pacquet's workload (short-lived buffers + geometric Vec growth + bounded concurrency) doesn't hit jemalloc's classic win cases (contended arenas, long-lived large objects).

Pushed f8388d7 — swap swc_malloc for mimalloc directly, with an explicit #[global_allocator]. Tests mimalloc-vs-glibc instead of jemalloc-vs-glibc. Different allocator philosophy (per-thread free lists + small-object fast path) so it's worth one CI cycle.

Decision rule: if the next bench also shows this PR within noise of main, close it — the allocator swap doesn't deliver on the runner we measure against. If mimalloc wins, land the direct-mimalloc form.

Allocators rarely affect performance. And I don't think this is the performance bottleneck either.

Modern glibc is so good now. Improve upon it is hard. Proving its advantage is not easy.