type-hash: HashSet for unificationCache (-15.4% full build on pr-admin)

[kozak]

Summary

• Step 1: Cache a structural Int hash on every Type node alongside the existing TypeFlags, computed at construction by combining children's cached hashes with a per-constructor salt. Adds Hashable (Type a) (O(1) via the cached field) and Hashable (Constraint a).
• Step 3: Switch the unificationCache in Unify.hs:121–123 from Set (Type, Type) to HashSet (Type, Type). This drops compareType from the unification cache hot path entirely.
• Measured -15.4% on full builds of pr-admin (median of 4, 47515-49155 ms; tight). Neutral on the three incremental scenarios.
• Ord Type is deliberately unchanged — see the rust-interning Phase 2 trap in LESSONS.md.

compareType was the new top hotspot at 7.7% post-merges (after synonym-opt + skip-redundant-entailment-unify shipped). The unification cache is the largest single source.

Final results (vs baseline 799e8208)

Scenario	Base (s)	Head (s)	Δ	Notes
full	57.0	48.2	-15.4%	tight, 47515-49155 ms
nochange	0.6	0.6	-1.9%	tight, 564-594 ms
prelude	4.0	4.0	-0.3%	within noise
leaf	1.6	1.6	-1.1%	very noisy (1550-8576 ms)

Two non-obvious implementation details

Both look like minor codegen hints but each is a 2× swing on full builds when missed. Documented in experiments/LESSONS.md:

1. {-# UNPACK #-} on the !TypeFlags field of every Type constructor. TypeFlags went from newtype (zero-cost wrapper) to a 2-field record; without UNPACK every Type allocation indirects through an extra boxed object — measured +107% on full. With UNPACK, the regression collapses to ~+1.8%.
2. {-# INLINE #-} on the Hashable Type instance methods. Without it GHC dispatches through the class dictionary at every hash call, allocates thunks, and the supposed HashSet win measures worse than Set (+102% on full). With INLINE the dictionary collapses through to a direct field read and the headline win drops out.

A eqType hash short-circuit (step 2) was tried and reverted — the hot callers (Entailment.hs:295 guard) compare equal types most of the time, so the hash check just adds work. See LESSONS.md.

Test plan

• stack test --fast: 1340 examples, 0 failures
• All four scenarios on pr-admin: full / nochange / prelude / leaf
• No Ord Type changes — iteration order preserved (rust-interning Phase 2 trap avoided)
• Reviewer eyeballs the new combineNodeFlags-style helpers and per-constructor salts in Types.hs

🤖 Generated with Claude Code

[zyla]

without UNPACK every Type allocation indirects through an extra boxed object — measured +107% on full.

Wow. This suggests there are probably more gains to be had by removing other indirections from Type. Or optimizing the layout in some other way. Pattern synonyms let us play some tricks.

For example (not suggesting we do that, it's crazy, but cool): in Zig they looked which type constructor patterns are most frequent and promoted them to top-level constructors - kinda like Huffman compression but for trees.

https://youtu.be/IroPQ150F6c?si=04SHZMYFiye-B7je&t=1567 - "encoding" approach. https://youtu.be/IroPQ150F6c?si=zufBypPxj1mwR1jy&t=2200 (same talk but later) - applied to Zig compiler AST

[zyla]

btw, now I wonder: do we still need the unification cache with skip-redundant-entailment-unify ? With it, unification might be close to eqType in performance for common cases (note: I haven't measured)

[kozak]

Claude checked something similar to what you are mentioning https://github.com/restaumatic/purescript/blob/restaumatic/experiments/LESSONS.md#the-unification-cache-is-a-hash-equal-memoizer-unify-pattern-survey . TLDR: it seems we do.

unify-cache Phase 2 (43f6b613, post-type-hash HashSet cache) — one-line drop (unifyTypes'' = unifyTypes'):
  - Full build: 51.8s → 64.3s (+24%)
  - Hit rate 39.3% (412k / 1.05M calls) — the cache saves ~12s for the ~10s of Hashable overhead it adds. Net positive ~12s.

  unify-pattern-survey Phase 2 — replaced cache with typeHash + eqType short-circuit upstream (different mechanism, but also "no cache
  lookup"):
  - full -2.8%, prelude +7.1%, others mixed.
  - Same shape as skip-redundant-funapp-unify Phase 2 (prelude +6.4%).

  So on the post-type-hash branch:
  - Drop entirely: +24% full.
  - Replace with eqType upstream guards: regresses prelude.
  - Keep as-is: optimal across all four scenarios.

  The cache pays for itself on full (39% hit rate amortises Hashable cost) and especially on prelude (cascade re-uses the same trivial
  pairs across 1342 modules — single HashSet bucket walk vs. re-walking via eqType).

  Pre-type-hash (799e8208, S.Set ordered cache) we never measured a clean drop, but the lookups are already O(1) on tiny constants so
  there's nothing to win there either — skip-redundant-funapp-unify Phase 1 was neutral.

  Conclusion captured in LESSONS.md: the cache-plus-Hashable infrastructure is essentially optimal for what it does; the path forward
  is elsewhere (e.g. compareType at 7.7%, attacked in type-hash).