Conversation
ad2619c to
8385621
Compare
| num-prime = "0.5.0" | ||
| num-traits = "0.2.19" | ||
| fancy-regex = { version = "0.19.1", default-features = false, features = [ | ||
| fancy-regex = { version = "0.19.2", default-features = false, features = [ |
There was a problem hiding this comment.
perhaps we could move the feature selection to src/uucore/Cargo.toml
Merging this PR will regress 1 benchmark
Warning Please fix the performance issues or acknowledge them on CodSpeed. Performance Changes
Tip Investigate this regression by commenting Comparing 
Footnotes
|
8385621 to
47d63dc
Compare
This comment was marked as outdated.
This comment was marked as outdated.
47d63dc to
a427a2b
Compare
|
GNU testsuite comparison: |
a427a2b to
257233c
Compare
This comment was marked as resolved.
This comment was marked as resolved.
846bee8 to
20880e0
Compare
wtcpython
changed the title
20880e0 to
cd53de5
Compare
|
@codspeedbot fix this regression |
Fixed in 3d05af4. What the report was actually showingThe regression was real, not noise: every memory benchmark in the tree gained exactly the same amount — +16 allocations, +4,752 bytes allocated, +4,187 bytes peak — including utilities that never compile a regex. Only the cheapest benchmarks crossed the reporting threshold, which is why the list looks arbitrary. I reproduced it locally with the CodSpeed CLI:
Cause
Growing that shared file therefore charges every benchmark. The eight new FixThe ids the error resource defines are now generated at build time and checked before the bundle is built, so a lookup that cannot be in there costs a
The regression is gone, and every benchmark drops the error-resource parse it was never supposed to pay — expect improvements across the board in the next report rather than a flat comparison. Validation: One caveat on the original report: its base was 94811cc rather than your merge base, and several benchmarks were compared across different CPU models. That did not affect this diagnosis — the memory numbers are byte-identical on both base runs — but it is worth reading the "Environment Differences" section before trusting any sub-10% simulation move on this repo. Summary
Was this response helpful? React with 👍 or 👎 to help us improve CodSpeedBot. |
|
@sylvestre The agent successfully pushed wtcpython@3d05af4 to the PR’s source branch, but GitHub did not synchronize the PR with the new commit. I’m investigating 👀 |
6ad71f6 to
73b9fbc
Compare
|
@sylvestre ready |
The error-only resource is parsed on the first lookup that misses every
ordinary bundle. That is not only an error path: a binary that cannot
resolve its own strings misses on every id it asks for, and a bench binary
calling `uumain` directly is exactly that. Every benchmark in the tree
therefore parsed the whole resource -- 106k of the 319k instructions
hostname_basic measures, and 16 allocations it never frees.
Growing the resource consequently charged every benchmark, whether or not
the utility can reach the new strings. The eight regex messages added here
moved hostname_basic from 318,823 to 335,034 instructions (+5.1%) and every
utility's peak memory by 4.2 KB, in utilities that never compile a regex.
Generate the ids the resource defines at build time and check that before
building the bundle, so a lookup that cannot be in there costs a match
instead of a parse:
hostname_basic instructions
main (94811cc) 318823
this branch 335034
this branch, this commit 212632
Measured with
`codspeed run --mode simulation -- cargo codspeed run -p uu_hostname`.
The expr benchmarks are unchanged (1,448,685 against 1,448,761 on main),
and expr still reports its regex diagnostics, in English and in French.
73b9fbc to
09138e9
Compare
No description provided.