| Age | Commit message (Collapse) | Author |
|---|
|
Composer shells out to `rm -rf` because PHP has no recursive directory removal.
Rust has one, and every package installed from a dist archive pays for a removal:
the extraction pipeline drops its temporary directory once per package, and
uninstalling a package removes its whole tree.
The asynchronous path goes through `tokio::fs` rather than `std::fs`, so the walk
runs on a blocking thread and the sibling installs the reactor is driving keep
making progress, the way they did while the subprocess was working.
Installing laravel/laravel (109 packages) from a warm cache drops from 3.85 to
3.19 CPU seconds. The removals run concurrently, so on an idle 16-core machine
they never reach the critical path and wall time is unchanged at 1.65 s; pinned
to two cores it falls from 2.33 s to 2.20 s. Pruning the 33 dev packages with
`install --no-dev`, where whole package trees are removed rather than empty
temporary directories, drops from 844 ms to 806 ms even on 16 cores.
Windows keeps the `rmdir /S /Q` subprocess, and both platforms keep falling back
to `remove_directory_php` when the fast path does not clear the directory.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
|
startCachedAsyncDownload's cached branch decoded the provider JSON into an
owned value and then rebuilt it entry by entry, recursively cloning every
package definition only to drop the original. Match the decoded value by
value instead. PHP hands the decoded array to the closure by COW, so no copy
happens there either.
laravel/framework require --no-install (warm cache, network disabled):
instructions:u 10276126917 -> 9884102191 (-3.8 %)
cycles:u 5048262624 -> 4777881212 (-5.4 %)
wall (hyperfine, 20 runs)
1.345 s +- 0.015 s -> 1.316 s +- 0.018 s (-2.2 %)
monolog/monolog is unchanged (100.7 ms -> 101.7 ms, within noise).
composer.lock is byte-identical for both packages.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
|
Benchmarks were comparing against whatever composer happened to be on
PATH instead of the pinned submodule version, and paid the HTTP/3
fallback penalty from composer/composer#12987 on every packagist
request.
|
|
A dead worker and a live one hitting a framing bug both surface as a
raw socket I/O error (e.g. "Broken pipe"), which doesn't say whether
the child crashed, was signaled, or is still running. Query the
child's exit status via try_wait() and attach it as anyhow::Context
so the panic message shows the root cause directly.
|
|
The earlier measurements documented in the perf notes were taken with
--no-audit to keep the security-advisories request out of the timings,
but the flag never landed in the committed script. Add it so future
runs are comparable.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
|
regex::Regex::clone() does not share the underlying meta engine's
search-cache pool, so every fresh clone pays a ~10us warmup cost on
its first use. Two changes together eliminate this across nearly all
preg_* call sites:
- A php_regex! macro resolves PHP-style patterns to a per-call-site
&'static regex::Regex (via regex-macro's LazyLock), applied at the
majority of call sites throughout the codebase.
- Call sites still passing dynamic pattern strings go through
PATTERN_CACHE, which now stores Arc<(Regex, bool)> and hands out
Arc::clone()s instead of cloning the Regex itself.
PregPattern::resolve() returns a ResolvedPattern enum (Arc or
'static reference) rather than an owned Regex, so neither path ever
clones the Regex proper.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
|
Lighter-weight companion to scripts/bench/create-project.sh: compares
shirabe vs composer on dependency resolution alone (require --no-install
--no-audit), skipping the download/install step that dominates
create-project's runtime.
|
|
|
