Context
statum-graph::validate_graph(...) currently detects duplicate transition ids by storing seen ids in a Vec and calling contains(...) for each transition, which is O(n^2) in the number of transitions.
Why this is not an immediate PR blocker
- The current code is correct.
- This path is not known to be hot today.
- Switching directly to
HashSet would tighten the external generic contract for MachineDoc::try_from_graph(...) because it would require T: Hash, not just T: Copy + Eq.
Follow-up decision
Decide whether to:
- Keep the current external API and accept the linear scan because this is not a proven bottleneck, or
- Explicitly require
T: Hash for the external path and switch duplicate transition-id detection to a HashSet.
Relevant code
statum-graph/src/lib.rs validate_graph(...)
statum-core/src/introspection.rs MachineIntrospection::TransitionId already requires Hash for Statum-generated graphs
Acceptance criteria
- Either document why the current
Vec approach is intentional, or
- Change the bound and implementation deliberately rather than as an incidental micro-optimization.
Context
statum-graph::validate_graph(...)currently detects duplicate transition ids by storing seen ids in aVecand callingcontains(...)for each transition, which isO(n^2)in the number of transitions.Why this is not an immediate PR blocker
HashSetwould tighten the external generic contract forMachineDoc::try_from_graph(...)because it would requireT: Hash, not justT: Copy + Eq.Follow-up decision
Decide whether to:
T: Hashfor the external path and switch duplicate transition-id detection to aHashSet.Relevant code
statum-graph/src/lib.rsvalidate_graph(...)statum-core/src/introspection.rsMachineIntrospection::TransitionIdalready requiresHashfor Statum-generated graphsAcceptance criteria
Vecapproach is intentional, or