CI to automate build of cargo lockfiles on different Alpine releases for git-annex aports
https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/community/git-annex
![]() This is an easy win for parseKeyVariety: benchmarking old/parseKeyVariety time 1.515 μs (1.512 μs .. 1.517 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 1.515 μs (1.513 μs .. 1.517 μs) std dev 6.417 ns (4.992 ns .. 8.113 ns) benchmarking new/parseKeyVariety time 54.97 ns (54.70 ns .. 55.40 ns) 0.999 R² (0.999 R² .. 1.000 R²) mean 55.42 ns (55.05 ns .. 56.03 ns) std dev 1.562 ns (969.5 ps .. 2.442 ns) variance introduced by outliers: 44% (moderately inflated) For formatKeyVariety, using a Builder is marginally worse than building a String... (This is with criterion evaluating fully to nf not whnf) benchmarking old/formatKeyVariety time 434.3 ns (428.0 ns .. 440.4 ns) 0.999 R² (0.999 R² .. 1.000 R²) mean 430.6 ns (428.2 ns .. 433.9 ns) std dev 9.166 ns (6.932 ns .. 11.94 ns) variance introduced by outliers: 27% (moderately inflated) benchmarking Builder/formatKeyVariety time 526.5 ns (524.7 ns .. 528.8 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 526.1 ns (524.9 ns .. 528.5 ns) std dev 5.687 ns (3.762 ns .. 8.000 ns) Manually building the ByteString was better, but still slightly slower than String, due to innefficient need to S.pack . show the HashSize: benchmarking formatKeyVariety time 459.5 ns (455.8 ns .. 463.2 ns) 1.000 R² (0.999 R² .. 1.000 R²) mean 459.9 ns (457.4 ns .. 466.6 ns) std dev 11.65 ns (6.860 ns .. 21.41 ns) variance introduced by outliers: 35% (moderately inflated) So I cheated and made parseKeyVariety cache the original ByteString, for formatKeyVariety to use instead of re-building it. Final benchmark: benchmarking new/formatKeyVariety time 50.64 ns (50.57 ns .. 50.73 ns) 1.000 R² (0.999 R² .. 1.000 R²) mean 51.05 ns (50.60 ns .. 52.71 ns) std dev 2.790 ns (259.6 ps .. 5.916 ns) variance introduced by outliers: 75% (severely inflated) benchmarking new/parseKeyVariety time 71.88 ns (71.54 ns .. 72.24 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 71.97 ns (71.69 ns .. 72.47 ns) std dev 1.249 ns (910.7 ps .. 1.791 ns) variance introduced by outliers: 22% (moderately inflated) |
||
---|---|---|
Annex | ||
Assistant | ||
Backend | ||
Build | ||
CmdLine | ||
Command | ||
Config | ||
Database | ||
debian | ||
doc | ||
Git | ||
Limit | ||
Logs | ||
Messages | ||
P2P | ||
Remote | ||
RemoteDaemon | ||
standalone | ||
static | ||
templates | ||
Test | ||
Types | ||
Upgrade | ||
Utility | ||
.ghci | ||
.gitattributes | ||
.gitignore | ||
.mailmap | ||
Annex.hs | ||
Assistant.hs | ||
Backend.hs | ||
bash-completion.bash | ||
Benchmark.hs | ||
build.bat | ||
BuildFlags.hs | ||
BuildInfo.hs | ||
CHANGELOG | ||
CmdLine.hs | ||
Command.hs | ||
Common.hs | ||
Config.hs | ||
COPYRIGHT | ||
Creds.hs | ||
Crypto.hs | ||
ghci | ||
git-annex.cabal | ||
git-annex.hs | ||
git-union-merge.hs | ||
Git.hs | ||
Jenkinsfile | ||
Key.hs | ||
Limit.hs | ||
Logs.hs | ||
Makefile | ||
Messages.hs | ||
NEWS | ||
README | ||
Remote.hs | ||
Setup.hs | ||
stack-lts-9.9.yaml | ||
stack-windows.yaml | ||
stack.yaml | ||
Test.hs | ||
Types.hs | ||
Upgrade.hs |
git-annex allows managing files with git, without checking the file contents into git. While that may seem paradoxical, it is useful when dealing with files larger than git can currently easily handle, whether due to limitations in memory, checksumming time, or disk space. For documentation, see doc/ or <https://git-annex.branchable.com/>