sublime text 本身不提供运行耗时统计功能，必须通过自定义 build system 调用外部工具（如 windows 的 timer.exe、linux/macos 的 /usr/bin/time）或在 python 代码中嵌入 time.perf_counter() 实现；所有方案均需手动配置或修改代码，无一键开启方式。
Sublime Text 本身不提供运行耗时统计功能，必须通过自定义 Build System 调用外部计时工具或在代码中嵌入计时逻辑——没有“一键开启耗时显示”这种事，所有方案都绕不开配置或修改。
Windows 下用 timer.exe 测 C++/Python 等可执行程序
这是最稳定、毫秒级精度、且不干扰 stdout 的方式。但 timer.exe 不是系统自带，得自己下载并确保能被 Sublime 找到。
-
timer.exe必须放在PATH环境变量里，或者在 Build System 中写绝对路径，例如"C:/tools/timer.exe"；写相对路径或直接放项目目录下无效 - Build System 的
shell_cmd要写成命令字符串整体传给timer.exe，不是把timer当前缀拼接。错误写法：timer python -u "$file"；正确写法："timer "python -u \"$file\"""（双层转义，Windows 下尤其容易漏掉反斜杠） - 它只输出时间 + 分隔线，不捕获程序输出，所以 Python 脚本的
print仍会原样显示在 Sublime 控制台里 - 如果你用的是 MinGW 或 MSYS2 环境，别混用 bash 风格的
time，timer.exe是 Win32 原生程序，兼容性更好
Linux/macOS 下用 /usr/bin/time 获取真实耗时与内存峰值
Unix-like 系统自带的 /usr/bin/time 比 Windows 的 timer.exe 信息更全，但 macOS 默认 time 是 shell 内置命令，不支持格式化输出，必须显式调用完整路径。
- Build System 中写
"/usr/bin/time -f 'Time: %e s, Max RSS: %M KB' python -u "$file""，其中%e是真实经过时间（real），%M是最大物理内存占用（KB） - Mac 上如果报错
time: bad option，说明你调用的是bash内置time，不是/usr/bin/time，必须改路径 -
-f格式字符串会覆盖被测程序的 stdout —— 如果你既要看程序输出又要看耗时，得重定向，比如python -u "$file" 2>&1 | /usr/bin/time -f ... true，再配合shell_cmd的管道处理 -
/usr/bin/time输出含换行，Sublime 控制台会正常显示，但日志不易解析；如需自动化提取，建议改用脚本封装
Python 脚本内嵌 time.perf_counter() 快速验证某段逻辑
不想配 Build System、也不介意临时改代码时，这是最快捷的方式。它不依赖外部工具，精度高，且不受系统时钟调整影响。
- 优先用
time.perf_counter()，不用time.time()—— 后者可能因 NTP 校时跳变，导致负耗时 - 示例写法：
start = time.perf_counter(); do_something(); print(f"cost: {time.perf_counter() - start:.3f}s") - 注意：不要在
print后再算差值，避免 I/O 开销计入；想测纯逻辑，print应该放在计时块之外 - 如果函数被频繁调用，手动加计时代码会污染业务逻辑；此时不如用装饰器封装，但 Sublime 本身不提供运行时装饰器注入能力，仍需改源码
为什么不能用 Sublime 自带的 Build 结果面板直接看耗时？
因为 Build System 的输出是纯文本流，Sublime 不解析、不计算、不标注时间戳。所谓“运行时间”，是你让外部工具算好后打印出来的字符串，不是 Sublime 主动测量的结果。
- Build 控制台里看到的
0.123s是timer或/usr/bin/time输出的，不是 Sublime 统计的 - 如果你删掉 Build System 里的计时命令，只留
python -u "$file"，控制台就完全不会显示任何耗时 - 某些插件（如 CodeTime、WakaTime）统计的是“编辑活跃时长”，不是代码运行耗时，二者完全无关，别混淆
- 真正需要长期监控运行效率的场景（比如 CI 阶段性能回归），应该脱离编辑器，用
cProfile、hyperfine或pytest-benchmark这类专用工具
最易被忽略的一点：Build System 配置里所有路径、引号、转义都要严格匹配当前操作系统和 Shell 类型。Windows cmd 和 PowerShell 对引号处理不同，macOS zsh 和 bash 对空格的容忍度也不同——同一个 JSON 配置，在不同环境里可能一半生效、一半静默失败。
