4. 星载软件性能分析基础

星载软件的性能分析，与地面通用软件最大的区别在于：可用资源极度受限、观测手段不可随意引入、且分析行为本身不能破坏任务时序。地面常用的 gprof、perf、Valgrind 等工具，在星上往往无法直接部署——它们要么依赖操作系统内核支持，要么需要大量内存与文件系统，要么会引入不可接受的运行时扰动。因此，星载性能分析的核心问题不是"用什么工具"，而是"在星上有限条件下，如何以最小侵入获得可信的性能数据"。

本节围绕四类基础手段展开：代码插桩、硬件计数器、时序分析与功耗测量，并重点讨论它们在星载环境下的适配方法。

一、代码插桩：从"全量埋点"到"分级可控"

代码插桩是在源码或二进制中插入观测代码，记录函数进入/退出、关键分支、循环次数等。最朴素的做法是在每个函数首尾插入时间戳读取，但星载 CPU 主频通常只有几十到几百 MHz，一次高精度时间戳读取可能消耗数十到上百个时钟周期，若函数本身只有几百周期，插桩开销就会严重扭曲测量结果。

星载适配的关键是分级插桩：把插桩点分为三级。L1 为粗粒度，只在任务入口、出口和关键状态切换处打点，开销控制在 1% 以内，可长期开启；L2 为中等粒度，在主要功能函数边界打点，开销约 3%~8%，仅在性能排查阶段开启；L3 为细粒度，在热点循环内部打点，开销可能超过 20%，只在实验室或地面仿真环境使用。星上运行时通过一个可写的"插桩级别寄存器"动态切换，避免重新编译上注。

另一个适配点是时间戳来源。星载系统通常没有高精度 TSC，可用的是系统节拍计数器或专用定时器。若节拍为 1 ms，则无法测量微秒级函数；此时可用 CPU 周期计数器（若处理器支持）或外接逻辑分析仪在测试点采样。插桩数据不宜直接写文件，而应写入预分配的环形缓冲区，由遥测下行或地面测试时读取。

二、硬件计数器：不侵入的"性能探针"

许多星载处理器（如 SPARC V8、PowerPC 系列、部分 ARM）内置性能监控计数器（PMC），可统计指令数、缓存命中/失效、分支预测失败、总线访问次数等。硬件计数器不修改代码，开销几乎为零，是星上最理想的性能观测手段。

适配方法包括：第一，确认处理器是否支持 PMC 及可计数事件集，部分航天级处理器为降低功耗和面积会裁剪该功能；第二，配置计数器时需注意事件复用，同一计数器在不同时刻可切换事件，但切换本身有开销，应避免高频切换；第三，计数器溢出中断的处理要轻量，只做累加和清零，不做复杂计算；第四，读数需与任务调度对齐，否则会把空闲任务或中断处理混入统计。

例如，若测得某图像处理任务执行期间指令数为 2.4×10⁶，缓存失效次数为 1.8×10⁴，而理论最小失效次数约为 3×10³，则可判断存在明显的缓存冲突或数据布局问题，应优先优化访存模式，而非指令级优化。

三、时序分析：从"测得到"到"测得准"

时序分析关注任务响应时间、最坏执行时间（WCET）、抖动和截止期满足情况。星载软件的时序分析不能只靠平均值，必须关注最坏情况，因为一次超时可能导致姿态控制失稳或数据丢失。

星上适配的时序分析方法包括：使用高精度定时器在任务切换点打时间戳，记录每个任务的开始、结束和阻塞时间；利用 RTOS 的钩子函数（如任务切换钩子、空闲钩子）自动采集调度轨迹；对关键中断服务程序单独测量其执行时间，并考虑中断嵌套。测量时要注意时间戳读取本身的抖动，可通过多次测量取最小值来逼近真实执行时间。

一个实用的判断依据是：若某任务的平均执行时间为 8 ms，最坏执行时间为 22 ms，而周期为 25 ms，则虽然平均负载仅 32%，但最坏情况下余量只有 3 ms，一旦出现中断风暴或缓存抖动，就可能超时。此时应优化最坏路径，而非继续优化平均路径。

四、功耗测量：性能与能量的联合约束

星载软件的性能不能只看时间，还要看能量。功耗测量在星上通常通过电源管理芯片的电流采样或专用功耗监测电路实现，采样率有限，且难以区分软件模块的功耗贡献。

适配方法是任务级功耗归因：在任务切换时同步记录电流采样值和时间戳，将功耗曲线与任务执行区间对齐，估算各任务的能量消耗。由于采样率低，通常只能得到趋势而非精确值，但足以判断某任务是否异常耗能。例如，若某数据处理任务在相同数据量下电流明显高于历史基线，可能意味着缓存失效增多或总线争用加剧，应结合硬件计数器进一步定位。

此外，功耗测量应与温度、电压联合观察，因为星上电源电压波动和温度变化都会影响功耗读数，不能简单归因于软件。

五、四类手段的联合使用与判断逻辑

四类手段不是孤立的。实际星上性能排查通常遵循"先粗后细、交叉验证"的路径：先用硬件计数器判断是否存在缓存或分支异常，再用 L1 插桩定位到具体任务，然后用时序分析确认最坏路径，最后用功耗测量判断是否伴随异常能耗。若四类数据指向一致，结论可信度高；若相互矛盾，则需检查测量本身是否引入了扰动。

例如，某星载任务出现偶发超时。硬件计数器显示缓存失效次数在超时周期内突增 5 倍；L1 插桩显示超时发生在数据搬运函数；时序分析显示该函数最坏执行时间从 6 ms 升至 19 ms；功耗采样显示该周期电流上升约 12%。四者一致指向"数据布局导致缓存冲突加剧"，优化方向明确为调整数据对齐和分块大小，而非简单降低任务频率。

需要强调的是，星载性能分析的第一原则是"不干扰任务"。任何测量手段引入的开销、内存占用和时序扰动，都必须在上注前经过地面验证。性能数据本身也要纳入遥测管理，避免占用宝贵的下行带宽。只有在测量可信、扰动可控的前提下，性能分析结果才能作为优化决策的依据。