perf(aqua): use phf for baked registry lookups

[risu729]

Summary

• Rebased onto current main and narrowed this PR to the baked aqua standard registry lookup path only.
• Generate the baked aqua package and alias lookup tables as static phf::Map values instead of runtime LazyLock<HashMap<...>> values.
• Use phf_codegen in build.rs because the map entries are generated from the vendored aqua registry at build time.
• Keep build-time diagnostics for malformed baked aqua rows, duplicate canonical package IDs, package filename hash collisions, and alias collisions.
• Moved the mise registry PHF lookup change to the separate, non-stacked draft PR perf(registry): use phf for mise registry lookups #9769.

Performance impact

• Before this PR, the baked aqua package map and alias map were lazy runtime HashMaps. The first baked-registry lookup initialized the relevant LazyLock, allocated a heap table, and inserted all generated entries.
• After this PR, those lookup tables are generated as PHF tables at build time. Runtime lookup no longer builds or allocates the HashMap; the process uses static read-only map metadata plus the existing baked package byte slices.
• The large baked aqua package blobs are not decoded or copied at startup. They were already compiled with include_bytes! before this PR, and they remain static binary data now. The OS can still demand-page those read-only sections as they are touched.
• So this is not an across-the-board warmed lookup speedup. Warmed HashMap and PHF lookup are close in the microbenchmark. The clearer win is removing first-use map construction and runtime heap allocation for the baked registry maps.
• In the benchmark below, the old file map shape would allocate at least about 115.5 KiB of heap for the 2,179-entry HashMap bucket/control storage after first use. The alias map is smaller but had the same lazy-allocation pattern. The baked package bytes themselves are unchanged.

phf_codegen

• phf_codegen is appropriate for this PR because the keys and values are known only after build-script parsing/codegen, not as hand-written Rust source.
• The dependency reuses the already locked 0.11.x phf crates; phf_codegen is listed in cargo-machete ignores because it is used from the root build script.

Benchmark

The previous PR body had benchmark results from temporary commits 5c39d6635 / fe8be4c0e, but those measured the earlier stacked PR that also changed the mise registry lookup table. This PR is now aqua-only, so I reran a targeted baked aqua registry benchmark.

The benchmark was intentionally committed and then removed so the PR history keeps the source while the final diff stays clean:

• Added in d26a809f9 (test(aqua): add temporary registry lookup benchmark).
• Removed in 23553c1fc (test(aqua): remove temporary registry lookup benchmark).

Command:

MISE_BENCH_ROUNDS=10000 cargo run --release --bin bench_aqua_registry_lookup

Representative run from this environment:

entries: 2179
rounds: 10000
lookups/sample: 21790000
hashmap capacity: 3584
estimated runtime HashMap heap: >= 115.5 KiB

lookup	ns/lookup	total ms	checksum
phf	69.50	1514.35	107630400000
HashMap warmed	71.07	1548.63	107630400000

first-use path	total ms	checksum
HashMap build + first lookup	0.092135	16124
phf first lookup	0.000058	10361

Interpretation: warmed lookup is effectively comparable for this table and can vary run-to-run. The meaningful behavior change is that the baked registry no longer pays the first-use HashMap construction/allocation cost.

Tests

• cargo fmt --all -- --check
• cargo check -p mise --all-features
• cargo test -p mise aqua::standard_registry
• cargo test -p mise aqua::aqua_registry_wrapper
• cargo test -p aqua-registry

This PR body was generated by an AI coding assistant.

[gemini-code-assist]

Code Review

This pull request refactors the tool and Aqua registries to use phf (Perfect Hash Functions) for efficient compile-time lookups and rkyv for binary serialization of Aqua package definitions. The Aqua registry data has been moved to a vendor/ directory, and the aqua-registry crate was simplified by moving baked-in data logic to the main crate. Feedback was provided regarding the deserialize_string_map function, which currently fails to handle null values in YAML, potentially causing deserialization errors.

[greptile-apps]

Greptile Summary

This PR replaces the baked aqua registry's runtime LazyLock<HashMap> lookup tables with phf::Map statics generated by phf_codegen in build.rs, eliminating first-use heap allocation and HashMap construction. It also addresses two previously flagged build-time robustness gaps.

• aqua_registry_bytes_map_code and aqua_registry_string_map_code now emit phf_codegen::Map output instead of HashMap::from([...]), and AQUA_STANDARD_REGISTRY_FILES / AQUA_STANDARD_REGISTRY_ALIASES are declared as phf::Map statics directly.
• aqua_package_registries now emits a cargo:warning for any row skipped due to a missing canonical ID, and returns a hard build error on duplicate canonical IDs.
• aqua_registry_aliases_code now uses BTreeMap (replacing HashMap+sort) for deterministic alias ordering and returns a hard build error on alias collisions instead of silently overwriting.

Confidence Score: 5/5

Safe to merge — the change is a mechanical substitution of two static lookup tables from lazy-initialized HashMaps to compile-time PHF maps, with no change to the public API or lookup semantics.

The generated PHF tables are structurally validated at build time (collision errors abort the build before the binary is produced), the runtime lookup paths in standard_registry.rs are functionally identical, and the existing test suite covers canonical, alias, and path-only lookups. No behavioral regressions are expected.

No files require special attention.

Important Files Changed

Filename	Overview
build.rs	Replaces HashMap-based codegen for the baked aqua registry with phf_codegen::Map; adds build-time warnings for skipped malformed rows and hard errors for canonical ID and alias collisions; switches alias accumulator from HashMap+sort to BTreeMap for deterministic ordering.
src/aqua/standard_registry.rs	Swaps LazyLock statics for phf::Map statics; removes HashMap/LazyLock imports; lookup logic is unchanged apart from the PHF get/deref pattern.

_{Reviews (6): Last reviewed commit: "Merge branch 'main' into perf/phf-regist..." | Re-trigger Greptile}