预处理慢在阻塞式、非向量化、频繁内存分配；应预分配对齐缓冲区、用SIMD加速归一化、下沉至GPU端、避免隐式同步与冗余拷贝。
预处理本身不“慢”，慢在它常被写成阻塞式、非向量化、反复分配内存的黑箱操作——尤其在高并发或小批量场景下，CPU 往往卡在 memcpy、格式转换、归一化循环里，而不是等 GPU 计算。
避免每次推理都 new/delete 输入缓冲区
频繁动态分配会触发 malloc 争用和 TLB miss，尤其在多线程下更明显。TensorFlow Lite 的 typed_input_tensor<float>(0)</float> 返回的是已预分配好的内存地址，但如果你自己做预处理（比如从 OpenCV cv::Mat 拷贝到模型输入），别在每次 Invoke() 前都 new float[...] 再 memcpy。
- 提前申请一块固定大小的
std::vector<float></float>或aligned_alloc内存，对齐到 64 字节（适配 AVX-512） - 用
cv::cvtColor+cv::resize直接写入该缓冲区，避免中间cv::Mat分配 - 若输入尺寸固定（如 224×224），可复用同一块内存；若变化，按最大尺寸预分配并记录有效长度
用 SIMD 指令加速归一化与通道变换
把 pixel * scale + bias 这类逐像素操作写成标量循环，是 CPU 利用率低的主因之一。现代 x86 和 ARM 都支持向量化浮点运算，OpenCV 默认开启，但很多自定义预处理没用上。
- 用
cv::transform替代手写 for 循环：它底层调用 IPP 或 NEON，自动向量化 - 若必须手写（如 YUV→RGB+归一化一体化），用
__m256/vld4q_f32一次加载 8 个 float，批量计算 - 注意数据布局：NHWC 格式比 NCHW 更利于缓存局部性（尤其对小 batch），但某些后端（如 TensorRT）偏好 NCHW——确认你用的推理引擎是否要求特定 layout
把预处理逻辑下沉到 GPU 端（仅限 CUDA/TensorRT 场景）
CPU 预处理完再 memcpy 到 GPU，等于让 CPU 算两次（预处理 + 调度）、GPU 等一次。延迟大头常在这里，而非模型计算本身。
立即学习“C++免费学习笔记（深入）”；
- 在 TensorRT 中，用
IPluginV2或IPreprocessor插件把 resize/crop/normalize 封装进网络首层，输入直接喂原始uint8图像 - ONNX Runtime 支持自定义算子，可用 CUDA kernel 实现
ResizeAndNormalize，注册为com.microsoft::ResizeAndNormalize - 警惕隐式同步：GPU 预处理后若立刻
cudaMemcpy回 CPU 取结果，会强制等待，应保持 end-to-end GPU 流水线
绕过 OpenCV，用轻量级图像操作库减少开销
OpenCV 功能全，但启动时加载大量模块、内部做运行时 dispatch、带调试断言——在嵌入式或低延迟服务中属于冗余成本。
- 对纯 resize + normalize 场景，用 stb_image_resize（C99 单头文件）+ 手写 NEON/SSE 归一化，体积小、无依赖、编译期确定路径
- 若需 YUV 解码（如摄像头流），用 libyuv（Google 开源），它专为实时视频优化，
I420ToRGB24比 OpenCV 快 2–3 倍 - 避免
cv::imread/cv::imencode：它们内部调用 libjpeg-turbo，但有额外封装层；直接用 turbojpeg API 控制解码参数（如 subsampling、scaling factor）
真正难的不是“怎么写快”，而是“怎么让预处理和推理共享内存视图而不拷贝”——这需要推理引擎支持 zero-copy 输入（如 ONNX Runtime 的 Ort::Value::CreateTensor 接受外部指针），以及你对内存生命周期有完全控制权。否则，再快的 SIMD 也救不了 memcpy 的那一哆嗦。
