为何TurboJPEG将JPEG解压为BMP的速度慢于OpenCV？

核心问题：测试操作不对等 #

你当前的测试统计的是两类完全不同的操作开销，没有可比性：

• TurboJPEG计时范围是JPEG文件解码为原始像素数据的解压操作耗时
• OpenCV计时范围是已经完成解码、存放在内存中的像素数据编码为无压缩BMP格式写入缓冲区的操作耗时，BMP无压缩特性决定了该步开销极低，和JPEG解压的计算量差了一个数量级

其他可能影响测试结果的因素 #

1. OpenCV默认后端兼容问题：OpenCV 4.2.0版本默认已经将libjpeg-turbo作为JPEG编解码的默认后端，如果你没有手动编译OpenCV使用原版libjpeg，两者底层调用的是同一个编解码库，不存在性能差异
2. libjpeg-turbo编译优化不足：如果你使用的libjpeg-turbo是未开启SIMD优化的编译版本，性能会远低于官方标称值，官方的性能测试数据都是基于开启了对应架构SSE/AVX/NEON指令集优化的版本
3. 不必要的格式转换开销：你代码中指定的输出像素格式为TJPF_BGRX，如果原始JPEG是普通3通道格式，解码时会额外新增填充Alpha通道的开销，和OpenCV默认的BGR3通道格式不对等，增加了无效计算

优化方案 #

1. 修正测试逻辑：若要对比JPEG解码性能，需保证两者执行相同操作
   • 测试OpenCV解码耗时：计时范围覆盖cv::imdecode的全流程，提前将JPEG文件读入内存排除IO开销影响
   • 测试TurboJPEG解码耗时：保留当前tjDecompress2的计时范围即可，同样提前读入文件排除IO影响
2. 优化libjpeg-turbo编译参数：编译时开启对应CPU架构的SIMD指令集支持，开启O3优化等级，关闭调试符号
3. 对齐像素格式：根据输入JPEG的实际通道数选择匹配的输出格式，普通3通道JPEG选择TJPF_BGR即可，避免不必要的通道填充、转换开销
4. 批量处理场景优化：重复使用tjhandle实例，避免每次解码都执行初始化、销毁操作的额外开销
5. 大流量场景可结合多线程并行处理多张图片，充分利用CPU多核性能

内容的提问来源于stack exchange，提问作者Esther