数据结构优化：从PCL点云到Eigen矩阵的内存布局

做点云处理这么多年，我踩过最大的坑就是——数据结构没选对，性能直接腰斩。今天咱们就聊聊这个看似基础、实则致命的话题。

你想想看，一个百万级的点云，如果内存布局不合理，CPU缓存命中率低得可怜，算法跑起来就跟老牛拉破车似的。我刚开始做项目时也吃过这个亏，后来才慢慢摸清门道。

1. PCL点云的内存布局，你真的了解吗？

PCL里最常用的就是pcl::PointCloud<PointXYZ>。它的内部结构其实是一个std::vector<PointXYZ>。每个点包含x、y、z三个float，总共12字节。

但问题来了——PCL的PointXYZ结构体里还有padding（内存对齐）。在我的机器上，sizeof(pcl::PointXYZ)是16字节，而不是12。多出来的4字节就这么白白浪费了。

嗯，这里要注意——如果你处理的是千万级点云，这25%的浪费就意味着多占用几百MB内存。而且缓存利用率也低，因为每次加载一个点，实际上只用了其中12字节，另外4字节是无效数据。

2. 从PCL到Eigen：换个姿势，性能翻倍

我个人习惯是把PCL点云转成Eigen矩阵来处理。为什么？因为Eigen的矩阵是列主序存储，而且支持SIMD指令集优化。

具体怎么做？看代码：

// 传统方式：逐点拷贝
pcl::PointCloud<pcl::PointXYZ>::Ptr cloud(new pcl::PointCloud<pcl::PointXYZ>);
// ... 加载点云 ...

// 转换成Eigen矩阵（3行N列）
Eigen::Matrix<float, 3, Eigen::Dynamic> points(3, cloud->size());
for (size_t i = 0; i < cloud->size(); ++i) {
    points(0, i) = cloud->points[i].x;
    points(1, i) = cloud->points[i].y;
    points(2, i) = cloud->points[i].z;
}

这样做的好处是：后续所有矩阵运算都可以用Eigen的向量化操作。比如计算所有点到原点的距离：

// 向量化计算，一行搞定
Eigen::VectorXf distances = points.colwise().norm();

我在项目中遇到过，同样的KNN搜索算法，用Eigen矩阵比用PCL原生结构快了将近3倍。原因很简单——Eigen的矩阵在内存中是连续排列的，CPU预取机制能完美工作。

3. SoA vs AoS：数据布局的哲学之争

说白了，这就是结构体数组（AoS）和数组结构体（SoA）的选择问题。

PCL用的是AoS：

// AoS：每个点是一个结构体
struct Point {
    float x, y, z;
};
std::vector<Point> points;  // x,y,z,x,y,z,x,y,z,...

而SoA是这样的：

// SoA：每个坐标单独一个数组
struct PointCloudSoA {
    std::vector<float> x;  // x,x,x,...
    std::vector<float> y;  // y,y,y,...
    std::vector<float> z;  // z,z,z,...
};

什么时候用SoA？当你只需要处理某个坐标时。比如做地面滤波，主要看z值。用SoA的话，z数组在内存里是连续的一块，加载到缓存里全是有效数据。用AoS的话，加载一个z值，还得带上旁边的x和y，缓存利用率只有1/3。

我曾经做过一个实验：对100万个点做z值阈值滤波。SoA版本耗时2.3ms，AoS版本耗时6.8ms。差了3倍！

4. 自定义紧凑点结构体

如果你既想要AoS的便利性，又不想有内存浪费，那就自己动手写个紧凑结构体：

// 使用#pragma pack消除padding
#pragma pack(push, 1)
struct CompactPoint {
    float x, y, z;
    // 没有额外padding
};
#pragma pack(pop)

// 或者用__attribute__((packed))
struct __attribute__((packed)) CompactPoint2 {
    float x, y, z;
};

这样sizeof(CompactPoint)就是12字节，一点不浪费。但要注意——对齐访问的问题。有些ARM平台不支持非对齐访问，强行用会触发异常。x86平台倒是不怕，只是性能会略微下降。

我个人更推荐的做法是：

// 用union实现显式对齐控制
union PointData {
    struct { float x, y, z; };
    float data[3];  // 保证连续访问
};

这样既保持了结构体语义清晰，又能用data数组做批量操作。

5. 核心知识体系

下面这张图总结了本章的核心逻辑：

6. 实战建议

说了这么多，总结几条我自己的经验：

• 如果算法只处理单个坐标（比如z值滤波、地面分割），果断用SoA或Eigen矩阵的row向量
• 如果算法需要频繁访问所有坐标（比如ICP、NDT），用AoS或自定义紧凑结构体
• 如果点云规模超过500万，一定要考虑内存布局优化，否则性能瓶颈不在算法，在内存带宽
• 跨平台开发时，慎用#pragma pack，优先用Eigen的Map机制做零拷贝转换

// 零拷贝映射
Eigen::Map<Eigen::Matrix<float, 3, Eigen::Dynamic>> 
    points_map(reinterpret_cast<float*>(cloud->points.data()), 3, cloud->size());

嗯，数据结构优化这块就聊到这儿。记住一句话：选对布局，事半功倍；选错布局，事倍功半。下一章咱们聊聊更具体的滤波算法实现中的内存优化技巧。