我的性能优化悄悄禁用了这个 App 存在的意义
来源:dev.to — 2026-08-23
📋 概述
作者的健身分析应用 WhyRep 用"每次读取时从原始训练记录推导结论"的架构,随着数据量增长读取变慢,于是他做了一次"显而易见的优化":限制每次读取只取最近两周的数据,并把推导写在 KDoc 里、用五个全绿的测试护航后上线。但真实场景中,一名精英级健身者在长达四十周的平台期里做过一次减载(deload)——这本是正确做法——结果 App 就再也不提示"平台期"了。原因是 no-verdict 会话每次都会消耗一行预算却不计入连败次数,而作者只预留了一行备用,根本无法覆盖多条被跳过的会话。被计数的东西(连败次数)与被限制的东西(行数)不是同一数量,任何固定数值都会被某种减载序列超出。修复方案是把固定上限改成循环加宽窗口,直到能证明更早的数据不会再改变结论。
🔑 核心要点
- 把读取上限定成"最近两周"是错的:平台期按连续未进步会话计数,最宽窗口可达 14 次会话,对周更训练者意味着三个多月的数据。
- 一次减载发生在四十周平台期中间,App 就再也检测不到平台期,因为 no-verdict 会话消耗行预算却不计入连败。
- 被计数的连败次数与被限制的行数是两个不同数量,任何固定数字都会被某种序列超出,所以上限不能是常量。
- 修复用循环加宽窗口直到能证明更早数据不会改变结论,常见场景仍在第一次查询就收敛。
💡 金句
一个保留大部分行为的性能改动,其实不是性能改动——它是附带性能收益的行为改动。
👍 0
👎 0
← 返回 dev.to 首页