perf(transform): O(1) class-chain lookups in inliner shadowing analysis#5082
Conversation
method_lookup_is_unshadowed and class_chain_property_sets walked the class inheritance chain with an O(classes) linear scan per level (classes.iter().find()), making method-inlining candidate evaluation O(candidates * depth * classes) on deep hierarchies. Index classes by name once into a HashMap (entry().or_insert keeps the first class for a duplicate name, preserving the prior iter().find() first-match semantics — duplicate class names occur cross-module). Output is unchanged; only the lookup complexity drops to O(1) per chain level.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis PR optimizes class-lookup performance in the inline analysis module by replacing repeated linear searches over class lists with pre-built HashMap indices keyed by class name. Both ChangesInline Analysis Class Lookup Optimization
🎯 1 (Trivial) | ⏱️ ~5 minutes
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Replaces the O(classes) linear scan per inheritance level in the inliner's method-shadowing analysis with O(1) hash lookups.
What
method_lookup_is_unshadowedandclass_chain_property_sets(crates/perry-transform/src/inline/analysis.rs) walk the class inheritance chain (depth capped at 32) and at every level didclasses.iter().find(|c| c.name == name)— an O(number-of-classes) scan. Both functions are called once per inlinable-method candidate (frominline/mod.rsandinline/cross_module.rs), so candidate evaluation was effectivelyO(candidates × depth × classes). On modules with many classes and deep hierarchies (e.g. Effect-style codebases) this is wasted compile time.This indexes the class slice by name into a
HashMap<&str, &Class>once per call and does O(1) lookups during the walk.Correctness
HashMap::entry(...).or_insert(c)keeps the first class for a duplicate name, exactly matching the prioriter().find()first-match semantics. This matters: duplicate class names occur across modules (e.g. Effect's same-namedTypeinSchemaASTandParseResult). Compiler output is unchanged — only lookup complexity drops.Verification
cargo test --release -p perry-transform— all pass (30 tests).Pure compile-speed change; no runtime or codegen-output behavior change.
Summary by CodeRabbit