多维数组性能瓶颈源于内存布局与对齐：行优先存储要求最内层循环作用于最后一维；结构体需重排成员或显式对齐；切片可能破坏对齐，需检查并重建；连续多维数组适合固定尺寸高频扫描，锯齿数组适合变长行场景。
多维数组的性能瓶颈，往往藏在内存布局和对齐细节里——不是算法不够快，而是数据没“站对位置”。关键不在维度数量，而在访问方式是否匹配硬件读取习惯。
行优先布局决定访问效率
主流语言（C/C++、C#、NumPy）默认采用行优先（row-major）存储：二维数组 arr[i][j] 在内存中是连续铺开的，先存完第0行所有列，再存第1行……这意味着 沿最后一维（列）遍历时，地址连续、缓存友好。
- 推荐遍历顺序：外层循环控制行（i），内层控制列（j）
- 反向遍历（先j后i）会导致每次访问跨步跳转，缓存行反复加载，性能可能下降2–5倍
- 三维及以上数组同理：最内层循环应作用于最后一个下标，如
arr[i][j][k]中，k应为最内层循环变量
结构体数组是对齐高危区
当多维数组元素是自定义结构体时，对齐问题立刻凸显。例如：
struct Pixel { char r; double val; };
若未重排成员，val（需8字节对齐）会因前面的 r 被挤到偏移1处，触发编译器插入7字节填充；整个结构体变成16字节，但数组首地址若非16的倍数，每个 val 都会未对齐。
- 把大成员（double、指针）放在结构体开头，小成员（char、bool）集中放后面，减少内部填充
- 用
alignas(16)显式声明结构体对齐要求，尤其适用于SIMD或GPU访存场景 - 分配数组时用
aligned_alloc或_aligned_malloc，确保起始地址满足对齐约束
避免切片破坏对齐
动态操作（如 NumPy 切片、PyTorch view）常导致视图脱离原始对齐边界。例如 tensor[:, 1:] 可能使数据指针不再满足16字节对齐，后续向量化指令（如 AVX）可能降级或报错。
- 检查对齐状态：
tensor.data_ptr() % 16 == 0（常见对齐粒度为16） - 必要时用
torch.clone()或np.ascontiguousarray()强制重建连续且对齐的副本 - 构造张量时指定
dtype和device后，优先用torch.empty(..., pin_memory=True)预分配对齐内存
锯齿数组 vs 多维数组：权衡连续性与灵活性
规则矩阵运算中，int[,]（C#）或 np.ndarray（NumPy）提供连续内存，利于缓存；但索引计算开销略高。而 int[][] 或 list[np.ndarray] 每行独立分配，行内连续、访问更快，但行间不连续，跨行访问易缓存未命中。
- 固定尺寸、高频扫描场景（如图像卷积核遍历）：优先选连续多维数组 + 正确循环顺序
- 变长行、频繁单行操作（如文本序列处理）：锯齿结构更高效，且便于内存池复用
- C++中可结合
std::vector<:array n>></:array>实现行内连续+编译期长度已知的平衡
