解析 Cache-Friendly 代码：利用数据定向布局（SoA vs AoS）消除 90% 的内存延迟

欢迎来到本次关于“Cache-Friendly 代码：利用数据定向布局（SoA vs AoS）消除 90% 的内存延迟”的讲座。在现代计算机系统中，CPU 的处理速度与主内存（RAM）的访问速度之间存在着巨大的鸿沟。这个速度差距，我们称之为“内存墙”（Memory Wall），是制约许多高性能应用的关键瓶颈。今天，我们将深入探讨如何通过精心设计数据布局，有效利用 CPU 缓存，从而显著提升程序的性能，甚至在特定场景下将内存延迟降低 90%。

1. 内存墙的挑战与 CPU 缓存的诞生

我们的旅程从理解现代计算机架构的核心挑战——内存墙开始。几十年来，CPU 的时钟频率和执行单元数量以惊人的速度增长，然而，主内存（DRAM）的访问延迟却改进缓慢。一块高性能 CPU 可能在几纳秒内执行一条指令，但从主内存中读取一个数据可能需要几十到几百纳秒，这相当于 CPU 空等数百个甚至上千个时钟周期。

为了弥补这一巨大的性能差距，CPU 设计者引入了多级缓存系统（Cache Hierarchy）。缓存是位于 CPU 内部或非常靠近 CPU 的小容量、高速存储器。它们的工作原理是基于“局部性原理”（Principle of Locality）：

1. 时间局部性（Temporal Locality）：如果一个数据项在某个时间点被访问，那么在不久的将来它很可能再次被访问。
2. 空间局部性（Spatial Locality）：如果一个数据项在某个时间点被访问，那么它附近的内存地址中的数据项很可能在不久的将来被访问。

当 CPU 需要一个数据时，它首先检查最快、最小的 L1 缓存。如果数据不在 L1 中，它会检查 L2 缓存，然后是 L3 缓存，最后才不得不访问主内存。每次从主内存中读取数据时，CPU 不仅会读取所需的数据，还会将该数据周围的一块连续内存区域（称为“缓存行”或“Cache Line”）一并加载到缓存中。典型的缓存行大小是 64 字节。

下表简要展示了不同存储介质的典型访问延迟：

存储介质	典型容量	典型访问延迟
CPU 寄存器	几百字节	< 1 纳秒
L1 缓存	几十 KB	0.5 – 1.5 纳秒
L2 缓存	几百 KB – 几 MB	4 – 12 纳秒
L3 缓存	几 MB – 几十 MB	15 – 50 纳秒
主内存 (DRAM)	几 GB – 几百 GB	50 – 200 纳秒
SSD	几百 GB – 几 TB	几万 – 几十万 纳秒
HDD	几 TB – 几十 TB	几百万 – 几千万 纳秒

从表中可以看出，从 L1 缓存获取数据的速度比从主内存快了约 100 倍甚至更多。这意味着，如果我们的代码能够最大限度地利用缓存，将大量主内存访问转化为缓存命中，就能获得巨大的性能提升。而数据布局，正是影响缓存利用率的关键因素之一。

2. 数据布局策略：AoS (Array of Structs) vs. SoA (Struct of Arrays)

现在我们进入本次讲座的核心：两种基本的数据布局策略——结构体数组（Array of Structs, AoS）和数组的结构体（Struct of Arrays, SoA），以及它们如何影响缓存性能。我们将使用一个粒子物理模拟的例子来贯穿始终，其中每个粒子都包含位置 (x, y, z)、速度 (vx, vy, vz) 和质量 (mass) 等属性。

2.1 结构体数组 (AoS)：面向对象的直观选择

AoS 是最常见、最直观的数据组织方式，尤其是在面向对象编程（OOP）中。我们定义一个结构体或类来封装一个实体（例如，一个粒子）的所有属性，然后创建一个该结构体类型的数组。

代码示例：AoS 布局

#include <iostream>
#include <vector>
#include <chrono>
#include <numeric> // For std::iota

// 定义一个表示粒子的结构体
struct ParticleAoS {
    float x, y, z;      // 位置
    float vx, vy, vz;   // 速度
    float mass;         // 质量

    // 假设还有其他不常访问的属性，例如颜色、生命值等
    int id;
    bool active;
    // ...
};

// 模拟更新所有粒子位置的函数
void update_positions_aos(std::vector<ParticleAoS>& particles, float dt) {
    for (size_t i = 0; i < particles.size(); ++i) {
        // 访问 x, y, z, vx, vy, vz
        particles[i].x += particles[i].vx * dt;
        particles[i].y += particles[i].vy * dt;
        particles[i].z += particles[i].vz * dt;
    }
}

// 模拟计算总质量的函数（只访问 mass）
float calculate_total_mass_aos(const std::vector<ParticleAoS>& particles) {
    float total_mass = 0.0f;
    for (size_t i = 0; i < particles.size(); ++i) {
        total_mass += particles[i].mass; // 只访问 mass
    }
    return total_mass;
}

// 模拟一个更复杂的操作，需要访问所有或大部分属性
void complex_operation_aos(std::vector<ParticleAoS>& particles, float gravity_const) {
    for (size_t i = 0; i < particles.size(); ++i) {
        // 假设这里需要访问所有属性进行一些复杂的物理计算
        particles[i].vx += gravity_const * (particles[i].mass / (particles[i].y + 1.0f));
        // ... 更多复杂的计算
    }
}

int main() {
    const int NUM_PARTICLES = 1000000;
    std::vector<ParticleAoS> particles_aos(NUM_PARTICLES);

    // 初始化数据
    for (int i = 0; i < NUM_PARTICLES; ++i) {
        particles_aos[i] = {
            (float)i, (float)i, (float)i, // x,y,z
            1.0f, 2.0f, 3.0f,            // vx,vy,vz
            10.0f + (float)i / NUM_PARTICLES, // mass
            i, true                      // id, active
        };
    }

    float dt = 0.01f;
    float gravity_const = 9.8f;

    // 性能测试：更新位置
    auto start_time = std::chrono::high_resolution_clock::now();
    update_positions_aos(particles_aos, dt);
    auto end_time = std::chrono::high_resolution_clock::now();
    std::chrono::duration<double, std::milli> duration = end_time - start_time;
    std::cout << "AoS - Update positions took: " << duration.count() << " msn";

    // 性能测试：计算总质量
    start_time = std::chrono::high_resolution_clock::now();
    float total_mass = calculate_total_mass_aos(particles_aos);
    end_time = std::chrono::high_resolution_clock::now();
    duration = end_time - start_time;
    std::cout << "AoS - Calculate total mass took: " << duration.count() << " ms (Total Mass: " << total_mass << ")n";

    // 性能测试：复杂操作
    start_time = std::chrono::high_resolution_clock::now();
    complex_operation_aos(particles_aos, gravity_const);
    end_time = std::chrono::high_resolution_clock::now();
    duration = end_time - start_time;
    std::cout << "AoS - Complex operation took: " << duration.count() << " msn";

    return 0;
}

AoS 布局的缓存行为分析：

当 CPU 访问 particles[i].x 时，它会加载 ParticleAoS 结构体所在的缓存行。由于 ParticleAoS 的所有成员（x, y, z, vx, vy, vz, mass, id, active 等）都存储在内存中的连续区域，因此这个缓存行会包含 x, y, z, vx, vy, vz, mass 以及其他一些属性。

• 优点：

  • 封装性好，代码直观： 一个 ParticleAoS 对象包含了所有相关数据，符合直觉。
  • 当需要访问一个实体所有属性时性能良好： 如果 update_positions_aos 函数需要同时访问 x, y, z, vx, vy, vz，那么加载一个缓存行后，后续对同一个 ParticleAoS 对象中这些属性的访问将很可能是缓存命中，因为它们都在同一个缓存行中。complex_operation_aos 函数也属于这种情况。

• 缺点：

  • 空间局部性利用不足（当只访问部分属性时）： 考虑 calculate_total_mass_aos 函数。它只需要访问 mass 属性。然而，当 CPU 加载 particles[i].mass 时，整个 ParticleAoS 结构体（包括 x, y, z, vx, vy, vz, id, active 等）都会被加载到缓存行中。这意味着缓存行中大部分数据（除了 mass）是当前操作不需要的“脏数据”。
  • 缓存污染： 随着循环的进行，每次只获取 mass 都会将整个结构体加载到缓存，从而将有用的缓存空间挤占掉。如果 ParticleAoS 结构体很大，并且缓存行一次只能容纳少数几个 ParticleAoS 对象，那么缓存可能会频繁地失效，导致大量缓存未命中，性能下降。

假设一个 ParticleAoS 结构体大小是 7 * sizeof(float) + sizeof(int) + sizeof(bool)，大约 7*4 + 4 + 1 = 33 字节。如果一个缓存行是 64 字节，那么一个缓存行可以容纳一个 ParticleAoS 结构体和一部分下一个 ParticleAoS 结构体。当只访问 mass 时，每次加载 64 字节，但只使用了其中 4 字节，这是一种极大的浪费。

2.2 数组的结构体 (SoA)：面向数据的优化选择

SoA 布局与 AoS 相反，它将所有相同类型的属性组织成独立的数组。换句话说，不是一个粒子有所有属性，而是所有粒子的 x 坐标在一个数组里，所有粒子的 y 坐标在另一个数组里，以此类推。

代码示例：SoA 布局

#include <iostream>
#include <vector>
#include <chrono>
#include <numeric> // For std::iota

// 定义一个表示所有粒子属性的结构体（存储数组）
struct ParticlesSoA {
    std::vector<float> x, y, z;      // 位置数组
    std::vector<float> vx, vy, vz;   // 速度数组
    std::vector<float> mass;         // 质量数组

    // 假设还有其他不常访问的属性
    std::vector<int> id;
    std::vector<bool> active;

    size_t size() const {
        return x.size();
    }

    void resize(size_t new_size) {
        x.resize(new_size);
        y.resize(new_size);
        z.resize(new_size);
        vx.resize(new_size);
        vy.resize(new_size);
        vz.resize(new_size);
        mass.resize(new_size);
        id.resize(new_size);
        active.resize(new_size);
    }
};

// 模拟更新所有粒子位置的函数
void update_positions_soa(ParticlesSoA& particles, float dt) {
    for (size_t i = 0; i < particles.size(); ++i) {
        // 访问 x, y, z, vx, vy, vz 数组的第 i 个元素
        particles.x[i] += particles.vx[i] * dt;
        particles.y[i] += particles.vy[i] * dt;
        particles.z[i] += particles.vz[i] * dt;
    }
}

// 模拟计算总质量的函数（只访问 mass 数组）
float calculate_total_mass_soa(const ParticlesSoA& particles) {
    float total_mass = 0.0f;
    for (size_t i = 0; i < particles.size(); ++i) {
        total_mass += particles.mass[i]; // 只访问 mass 数组
    }
    return total_mass;
}

// 模拟一个更复杂的操作，需要访问所有或大部分属性
void complex_operation_soa(ParticlesSoA& particles, float gravity_const) {
    for (size_t i = 0; i < particles.size(); ++i) {
        // 假设这里需要访问所有属性进行一些复杂的物理计算
        particles.vx[i] += gravity_const * (particles.mass[i] / (particles.y[i] + 1.0f));
        // ... 更多复杂的计算
    }
}

int main() {
    const int NUM_PARTICLES = 1000000;
    ParticlesSoA particles_soa;
    particles_soa.resize(NUM_PARTICLES);

    // 初始化数据
    for (int i = 0; i < NUM_PARTICLES; ++i) {
        particles_soa.x[i] = (float)i;
        particles_soa.y[i] = (float)i;
        particles_soa.z[i] = (float)i;
        particles_soa.vx[i] = 1.0f;
        particles_soa.vy[i] = 2.0f;
        particles_soa.vz[i] = 3.0f;
        particles_soa.mass[i] = 10.0f + (float)i / NUM_PARTICLES;
        particles_soa.id[i] = i;
        particles_soa.active[i] = true;
    }

    float dt = 0.01f;
    float gravity_const = 9.8f;

    // 性能测试：更新位置
    auto start_time = std::chrono::high_resolution_clock::now();
    update_positions_soa(particles_soa, dt);
    auto end_time = std::chrono::high_resolution_clock::now();
    std::chrono::duration<double, std::milli> duration = end_time - start_time;
    std::cout << "SoA - Update positions took: " << duration.count() << " msn";

    // 性能测试：计算总质量
    start_time = std::chrono::high_resolution_clock::now();
    float total_mass = calculate_total_mass_soa(particles_soa);
    end_time = std::chrono::high_resolution_clock::now();
    duration = end_time - start_time;
    std::cout << "SoA - Calculate total mass took: " << duration.count() << " ms (Total Mass: " << total_mass << ")n";

    // 性能测试：复杂操作
    start_time = std::chrono::high_resolution_clock::now();
    complex_operation_soa(particles_soa, gravity_const);
    end_time = std::chrono::high_resolution_clock::now();
    duration = end_time - start_time;
    std::cout << "SoA - Complex operation took: " << duration.count() << " msn";

    return 0;
}

SoA 布局的缓存行为分析：

当 CPU 访问 particles.mass[i] 时，它会加载 mass 数组中 particles.mass[i] 所在的缓存行。由于 mass 数组中只存储 float 类型的质量数据，所以这个缓存行将包含多个连续的 mass 值（例如，64 字节的缓存行可以容纳 16 个 float 值）。

• 优点：

  • 极佳的空间局部性（当只访问部分属性时）： 考虑 calculate_total_mass_soa 函数。它只需要访问 mass 数组。当 CPU 加载 particles.mass[i] 时，整个缓存行将填充着 mass[i], mass[i+1], ..., mass[i+15] 等数据。这些数据都是当前操作需要的，因此后续对 mass 数组的访问将非常高效，几乎都是缓存命中。缓存利用率达到 100%。这正是 SoA 能够显著减少内存延迟的关键所在。
  • 天然支持 SIMD（Single Instruction, Multiple Data）指令： SIMD 指令允许 CPU 一次性对多个数据执行相同的操作（例如，Intel SSE/AVX、ARM NEON）。SoA 布局将相同类型的数据连续存储，完美地契合了 SIMD 的需求，进一步提升计算密集型任务的性能。例如，可以一次性加载 4 个 float 或 8 个 float 进行并行运算。
  • 减少缓存污染： 不需要的数据根本不会被加载到缓存，从而避免了缓存污染，为真正需要的数据保留了宝贵的缓存空间。

• 缺点：

  • 封装性较差，代码不直观： 一个逻辑上的“粒子”被分散到多个数组中，这使得代码可能不如 AoS 直观，访问一个粒子的所有属性需要从多个数组中取值。
  • 当需要访问一个实体所有属性时性能可能下降： 考虑 complex_operation_soa 函数。它需要同时访问 x, y, vx, mass 等多个数组。每次迭代，CPU 需要从不同的内存位置（不同的数组）加载数据。这可能导致缓存未命中，因为 x[i], y[i], vx[i], mass[i] 分别位于不同的缓存行。虽然它们在各自的数组中是连续的，但这些数组本身在内存中通常是不连续的。这可能导致同时在缓存中保留多个不相关的缓存行，增加缓存压力。然而，现代 CPU 有足够多的缓存行来处理少量并行访问，所以对于合理数量的属性访问，SoA 仍然可能优于 AoS，因为每个缓存行携带的数据都是 100% 有用的。

3. 实际应用与性能提升

理解了 AoS 和 SoA 的优缺点后，关键在于何时选择哪种布局。

3.1 何时选择 AoS

• 当操作倾向于访问一个实体的所有或大部分属性时： 例如，序列化/反序列化整个对象，或者一个复杂的函数需要根据对象的多个内部状态进行计算。在 complex_operation 的例子中，如果粒子结构体不大，AoS 可能表现良好。
• 当数据规模较小，或者内存访问不是性能瓶颈时： 在这种情况下，代码的简洁性和可读性可能比极致的缓存优化更重要。
• 面向对象设计哲学： 如果系统强依赖于对象的封装和多态，AoS 是更自然的匹配。

3.2 何时选择 SoA

• 当操作倾向于访问大量实体中相同类型的属性子集时： 这是 SoA 布局发挥最大优势的场景。例如，更新所有粒子的 x 坐标，计算所有物体的总质量，或者渲染时只提取所有顶点的 position 和 normal 属性。
• 计算密集型任务，特别是可以利用 SIMD 指令的场景： 科学计算、物理模拟、图像处理、机器学习中的向量/矩阵运算等领域，SoA 布局能够提供显著的性能优势。
• 数据规模庞大，内存访问成为主要瓶颈时： 减少缓存未命中率是这类应用性能优化的重中之重。
• 游戏开发中的实体组件系统 (ECS)： ECS 架构通常采用 SoA 或混合 SoA/AoS 布局。每个“组件”可以看作是 SoA 中的一个属性数组，系统只处理它关心的组件数据。

3.3 混合布局与数据定向设计

在实际应用中，纯粹的 AoS 或纯粹的 SoA 往往不是最佳解决方案。一种常见的策略是采用混合布局。例如，在一个 Particle 结构体中，将经常一起访问的属性（如 x, y, z, vx, vy, vz）放在一起，形成一个小的 AoS 结构，而将不常访问或单独访问的属性（如 mass, id, active）分离到单独的数组中，或者将它们组织成另一个 SoA。

更进一步地，这种思考方式引出了“数据定向设计（Data-Oriented Design, DOD）”的理念。DOD 的核心思想是：优化数据布局以适应数据访问模式，而不是将数据组织成抽象的对象。 它的目标是最大化缓存命中率，最小化内存带宽使用，并促进 SIMD 友好型代码的编写。这意味着在设计数据结构时，首先考虑数据将如何被处理、哪些数据将一起被访问，然后据此组织数据。

3.4 量化“90% 内存延迟消除”的可能性

“消除 90% 的内存延迟”是一个大胆的声明，它指的是在内存访问成为绝对瓶颈的特定场景下，通过优化数据布局将大量昂贵的主内存访问转化为快速的缓存命中，从而带来性能的巨大提升。

考虑一个极端情况：

• 一个循环需要处理 100 万个 ParticleAoS 对象，每个对象 64 字节，总共 64MB 数据。
• 该循环只访问每个 ParticleAoS 的一个 float 成员（4 字节）。
• 假设每次缓存未命中都需要 100 纳秒从主内存加载一个 64 字节的缓存行。
• 在一个 AoS 布局中，每次访问一个 float 都会导致一个缓存行被加载，但只有 4 字节被利用，其余 60 字节是无用的。因此，每 NUM_PARTICLES 次访问，理论上会产生 NUM_PARTICLES * sizeof(ParticleAoS) / CACHE_LINE_SIZE 次缓存未命中（最坏情况）。
• 在一个 SoA 布局中，如果只访问 mass 数组，那么一个缓存行可以容纳 16 个 float。这意味着每 16 次 float 访问，只需要一次缓存未命中。

性能提升的计算示例：

假设需要访问 100 万个粒子的 mass 属性。

• AoS (最坏情况): 100 万次内存访问，每次加载 64 字节，但只使用 4 字节。假设每次都是缓存未命中，总延迟 = 1,000,000 * 100 ns = 100 毫秒。
• SoA (最佳情况): 只访问 mass 数组。每 16 个 float 数据需要一次缓存加载。总共 1,000,000 / 16 = 62,500 次缓存加载。总延迟 = 62,500 * 100 ns = 6.25 毫秒。

在这个理想化的例子中，SoA 的性能比 AoS 快了 100 / 6.25 = 16 倍。这意味着内存延迟减少了约 93.75%。

实际情况会更复杂，因为有L1/L2/L3多级缓存，预取器，以及CPU乱序执行等因素。但这个例子清晰地展示了，在内存带宽受限且访问模式高度局部化的场景下，SoA 布局能够带来的巨大性能潜力。通过将原本昂贵的 DRAM 访问转化为廉价的缓存访问，我们确实可以“消除”绝大部分的内存延迟。

4. 高级考量与权衡

4.1 缓存行对齐

为了最大化缓存效率，确保数据结构能够良好地对齐到缓存行边界非常重要。如果一个数据结构（或 SoA 中的一个数组的起始地址）没有与缓存行边界对齐，那么一个缓存行可能只包含它的一部分，而另一部分则跨越到下一个缓存行，导致需要加载两个缓存行才能获取完整的数据，这被称为“假共享”（False Sharing）的前兆，或仅仅是低效的缓存利用。

在 C++ 中，可以使用 alignas 关键字来指定内存对齐：

// 确保结构体对齐到缓存行大小（通常是 64 字节）
struct alignas(64) ParticleAoS_Aligned {
    float x, y, z, vx, vy, vz, mass;
    int id;
    bool active;
    char padding[64 - (7*sizeof(float) + sizeof(int) + sizeof(bool)) % 64]; // 填充以确保整个结构体是64字节的倍数
};

对于 SoA 布局，std::vector 通常会分配对齐的内存，但如果直接使用 new float[NUM_PARTICLES]，则需要手动确保对齐。

4.2 伪共享 (False Sharing)

当多个线程同时访问位于同一个缓存行但属于不同变量的数据时，即使这些变量在逻辑上不相关，缓存系统也会因为缓存行冲突而导致性能下降。当一个线程修改了缓存行中的某个数据，这个缓存行就会被标记为“脏”，并需要同步到其他所有持有该缓存行副本的 CPU 核心，从而引发昂贵的缓存一致性协议开销。

• AoS 布局和伪共享： 如果 ParticleAoS 结构体中有多个变量，并且不同线程独立地修改同一个 ParticleAoS 实例中的不同变量，但这些变量恰好位于同一个缓存行中，就可能发生伪共享。
• SoA 布局和伪共享： SoA 在某种程度上可以缓解伪共享。例如，如果线程 A 修改 particles.x[i]，线程 B 修改 particles.y[j]，如果 i 和 j 不相同，那么它们可能位于不同的缓存行，因为 x 和 y 是不同的数组。但是，如果多个线程并发地修改 x 数组中的相邻元素 particles.x[i] 和 particles.x[i+1]，而这两个元素恰好位于同一个缓存行中，那么仍然会发生伪共享。

为了避免伪共享，可以通过填充数据（padding）来确保不同线程访问的数据落在不同的缓存行中，或者重新设计数据访问模式。

4.3 代码复杂性与可读性

SoA 布局的缺点之一是可能增加代码的复杂性和降低可读性。一个逻辑上的“实体”被分解成多个数组，这使得我们无法像 myParticle.position.x 这样直观地访问其属性。代码可能变成 positions_x[i]、positions_y[i] 等，这在编写和维护时需要更多的注意力。

为了弥补这一缺点，可以引入一些封装层，例如使用代理对象或模板元编程来提供更友好的访问接口，同时在底层保持 SoA 布局。

// 示例：SoA 封装层
struct ParticleView {
    float& x, &y, &z;
    float& vx, &vy, &vz;
    float& mass;

    ParticleView(ParticlesSoA& soa, size_t index)
        : x(soa.x[index]), y(soa.y[index]), z(soa.z[index]),
          vx(soa.vx[index]), vy(soa.vy[index]), vz(soa.vz[index]),
          mass(soa.mass[index]) {}
};

// 使用封装层
void update_positions_soa_with_view(ParticlesSoA& particles, float dt) {
    for (size_t i = 0; i < particles.size(); ++i) {
        ParticleView p(particles, i);
        p.x += p.vx * dt;
        p.y += p.vy * dt;
        p.z += p.vz * dt;
    }
}

这种封装增加了抽象开销，但通常编译器可以优化掉这些开销。

4.4 内存占用与碎片

SoA 布局可能会导致更多的内存分配（每个属性一个 std::vector），这可能增加一些管理开销。此外，如果各个数组的生命周期不同步，可能会导致内存碎片化。然而，对于大型同构数据集，通常所有数组的大小都是相同的，并且一起分配/释放，因此碎片化问题并不突出。在某些情况下，SoA 由于不需要额外的对齐填充，甚至可能比 AoS 占用更少的内存。

总结

CPU 性能与内存延迟之间的鸿沟是现代软件开发中不可忽视的挑战。通过理解 CPU 缓存的工作原理和局部性原则，我们可以通过精心设计数据布局来显著提升程序性能。结构体数组（AoS）直观且适用于对象整体操作，但当仅访问部分属性时，可能导致缓存污染和低效。而数组的结构体（SoA）则通过将相同类型的属性连续存储，极大地提升了空间局部性，特别适用于数据并行和 SIMD 优化，能够在内存密集型场景下将内存延迟降低到传统 AoS 布局无法企及的水平。

然而，SoA 并非万能药，它可能增加代码复杂性，并需要对数据访问模式有深入的理解。在实践中，数据定向设计（DOD）的思想鼓励我们根据程序的具体计算需求来组织数据，结合 AoS、SoA 甚至混合布局的优点，以达到最佳的性能和可维护性平衡。始终记住，性能优化是一个迭代和测量的过程，没有银弹，只有最适合特定工作负载的解决方案。在实际应用中，务必进行性能分析和基准测试，以验证您的数据布局选择是否真的带来了预期的性能提升。