3. MERLIC项目性能评估基准建立
在MERLIC项目里谈“性能优化”，第一步不是改参数，而是建立可复现的评估基准。没有基准，任何“变快了”都只是主观感受；有了基准，才能把优化前后的差异量化成可比较的数字。本节围绕四类关键性能指标（KPI）、基准测试设计、数据采集与分析方法展开，目标是让你能为一套MERLIC视觉应用搭起一套可长期使用的性能标尺。
一、四类关键性能指标的定义与边界
MERLIC的性能不能只看“处理一张图要多久”。一个完整的视觉应用包含图像采集、预处理、工具链执行、结果输出与通信，任何一段都可能成为瓶颈。因此建议同时跟踪以下四类指标，并明确各自的测量边界。
- 处理时间（Processing Time）：从图像进入MERLIC处理链到结果可用的耗时，通常以毫秒计。需要区分“单帧处理时间”和“端到端延迟”——后者还包含相机曝光、传输和通信开销。MERLIC的Recipe执行时间可在工具链层面观察，但要注意它不包含相机取像时间。
- 吞吐量（Throughput）：单位时间内成功处理的图像数量，单位fps或件/分钟。吞吐量受处理时间、并行度和触发方式共同影响，是产线节拍匹配的核心指标。
- CPU/GPU占用：MERLIC多数工具以CPU为主，部分算子（如深度学习推理、图像滤波）可调用GPU。需分别记录平均占用率和峰值占用率，峰值往往决定系统是否会出现偶发卡顿。
- 内存消耗：包括MERLIC进程的常驻内存（Working Set）和图像缓冲区占用。长时间运行时若内存持续增长，说明存在图像或结果对象未释放的问题。
四类指标之间存在耦合：提高并行度可提升吞吐量，但会推高CPU占用；增大图像缓冲区可平滑抖动，但会增加内存。基准测试的价值就在于把这些耦合关系显性化。
二、基准测试设计：让每次测量都可复现
基准测试的核心是“控制变量”。同一组图像、同一台工控机、同一版MERLIC、同一套Recipe，只改变你要评估的那一个因素。建议按以下要素设计测试用例。
图像集：准备一组具有代表性的图像，覆盖正常件、边界件和缺陷件，数量建议不少于200张。图像分辨率必须与实际产线一致，因为分辨率对处理时间的影响近似线性甚至超线性。将图像放在本地SSD而非网络路径，避免I/O波动干扰。
运行模式：MERLIC支持单次执行和连续执行。基准测试应区分两种模式：单次执行测的是冷启动和单帧延迟，连续执行测的是稳态吞吐量。连续执行时建议先跑50帧作为预热，丢弃预热阶段数据，再采集后续200帧。
参数矩阵：把可能影响性能的参数列成矩阵，例如图像缩放比例、ROI大小、工具链中算子的并行开关、GPU加速开关。每次只改一个维度，记录对应的KPI变化。例如：
测试用例示例（教学假设参数）：
用例A：原始分辨率 2448×2048，ROI全图，CPU模式
用例B：原始分辨率 2448×2048，ROI缩小至中心1024×1024，CPU模式
用例C：原始分辨率 2448×2048，ROI全图，GPU加速开启
用例D：降采样至1224×1024，ROI全图，CPU模式
每组连续采集200帧，记录：
- 平均处理时间、P95处理时间
- 平均吞吐量
- CPU平均/峰值占用
- 进程常驻内存峰值注意：以上参数为教学示例，实际项目中应根据相机型号、镜头视野和检测精度要求确定。
三、数据采集：从哪些位置取数
MERLIC本身提供Recipe执行时间的观察入口，但要做精细分析，建议组合使用以下采集手段：
- MERLIC日志与Recipe计时：在MERLIC中启用执行时间记录，可得到工具链整体耗时。若需定位到单个工具，可在工具链中插入计时工具或利用MERLIC的日志级别输出。
- Windows性能计数器：用
typeperf或性能监视器采集\Process(MERLIC)\% Processor Time、\Process(MERLIC)\Working Set，采样间隔建议1秒，连续记录整个测试过程。 - GPU采集：NVIDIA平台可用
nvidia-smi --query-gpu=utilization.gpu,memory.used --format=csv -l 1按秒记录；若使用其他GPU，可用GPU-Z的日志功能。 - 自定义时间戳：在图像触发和结果输出处打时间戳，写入CSV，用于计算端到端延迟。时间戳应使用同一时钟源，避免跨进程时钟偏差。
四、数据分析：从原始数据到可执行结论
采集到的原始数据不能只看平均值。处理时间的分布往往存在长尾，P95和P99更能反映产线实际体验。建议按以下顺序分析：
- 清洗：剔除预热帧、异常中断帧和明显受后台干扰的离群点，并记录剔除原因和数量。
- 统计：计算均值、中位数、标准差、P95、P99、最大值。若均值与中位数差距大，说明分布偏斜，需关注长尾。
- 对比：将优化前后的同一指标并列，计算变化率。例如处理时间从42ms降到31ms，降幅约26%；同时检查CPU占用是否从65%升到82%，判断代价是否可接受。
- 判定：结合产线节拍给出结论。若节拍要求为30件/分钟（即2秒/件），而端到端延迟P99为1.6秒，则满足要求且留有约20%余量；若P99达到2.1秒，则存在偶发超节拍风险，需要继续优化。
为了让基准可长期复用，建议把测试用例、环境信息、采集脚本和结果表统一归档，形成一份“性能基准卡”。后续每次修改Recipe或升级MERLIC版本，都用同一套基准卡复测，才能判断改动是真正提升了性能，还是仅仅换了一个瓶颈。