You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow-up from #163 (spike on predicting analyze --per-function-touches runtime ahead of time). Discussed there: a pre-flight runtime estimate is one way to avoid timeout crashes on large repos (see golang/go failing hotspots-cloud's 900s budget at 445MB — under its 500MB size-based cutoff for hybrid-touches routing).
This ticket tracks a different, complementary approach that doesn't depend on getting a predictive model right: make analyze self-correcting at runtime instead of requiring callers to predict cost upfront.
Proposal
While running --per-function-touches, track progress (functions processed / total, elapsed time) and expose a way to auto-downgrade to hybrid touches mid-run if the observed processing rate projects past a caller-supplied budget (e.g. --budget-seconds). This avoids:
Callers like hotspots-cloud currently guess the touch mode upfront from size_kb and hope the fixed external wall-clock timeout doesn't fire; a --budget-seconds + adaptive downgrade would let hotspots itself gracefully degrade instead of being killed from outside.
Motivation
Follow-up from #163 (spike on predicting
analyze --per-function-touchesruntime ahead of time). Discussed there: a pre-flight runtime estimate is one way to avoid timeout crashes on large repos (seegolang/gofailing hotspots-cloud's 900s budget at 445MB — under its 500MB size-based cutoff for hybrid-touches routing).This ticket tracks a different, complementary approach that doesn't depend on getting a predictive model right: make
analyzeself-correcting at runtime instead of requiring callers to predict cost upfront.Proposal
While running
--per-function-touches, track progress (functions processed / total, elapsed time) and expose a way to auto-downgrade to hybrid touches mid-run if the observed processing rate projects past a caller-supplied budget (e.g.--budget-seconds). This avoids:analyzeruntime ahead of time to avoid timeout crashes on large repos #163 may or may not produce one that generalizes well)Notes
analyzeruntime ahead of time to avoid timeout crashes on large repos #163 (a rough pre-flight estimate could set a smarter default budget, but isn't required for this to work).size_kband hope the fixed external wall-clock timeout doesn't fire; a--budget-seconds+ adaptive downgrade would let hotspots itself gracefully degrade instead of being killed from outside.Related
analyzeruntime ahead of time to avoid timeout crashes on large repos #163 (predictive runtime spike)