[ty] Use SmallVec for CycleDetector::seen#26181
Conversation
Typing conformance resultsNo changes detected ✅Current numbersThe percentage of diagnostics emitted that were expected errors held steady at 94.37%. The percentage of expected errors that received a diagnostic held steady at 89.00%. The number of fully passing files held steady at 94/134. |
Memory usage reportMemory usage unchanged ✅ |
|
Merging this PR will improve performance by 5.36%
Performance Changes
Tip Curious why this is faster? Use the CodSpeed MCP and ask your agent. Comparing Footnotes
|
|
How frustrating that this is faster 😆 |
CycleDetector::seen
AlexWaygood
left a comment
There was a problem hiding this comment.
Ugh, our CycleDetector was already an overabstraction with too many generic parameters 😆 but this is awesome, thanks
Store the
CycleDetector::seenin aSmallVecinstead of aFxIndexSet. We always push a type intoseen, even if this ends being the only type that we visited. Today, this always results in an allocation.This PR uses a
SmallVecfor seen instead.As you can see, almost all
CycleDetectorsstore at most 2-3 elements, in which case a simple vectorcontainsis much faster.I was worried about what if
seengrows very large. However, running ty over all ecosystem projects: maximum 52 inmitmproxyfor six detectors; another eight reached 51. The next-highest project maximum was only 14.So there are a few large
seentables but they're still bound where aO(n)scan is reasonable. On top, our current implementation is alreadyO(n), and a largerseenalso results in a much deeper stack because seen tracks stack depth. That's why I think aVec(or small vec) is perfectly fine here. Especially because it does perform better than my small set implementation #26171Performance
See Codspeed report. This also helps reduce allocations by a lot (up to 5.6% for some projects)