1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# 第一步：编译时保留符号（Release 级优化 + 调试信息）
cmake -B build -DCMAKE_BUILD_TYPE=RelWithDebInfo

# 第二步：采样记录
# -F 97：采样频率 97Hz（用 97 而非 100，避免与系统时钟谐振）
# -g --call-graph dwarf：采集完整调用栈（dwarf 比 fp 更准确）
perf record -F 99 -g --call-graph dwarf ./build/my_server

# 第三步：在 TUI 中查看报告
perf report --no-children
# --no-children：只看函数自身 CPU 占比（self%），不含子函数
# 默认的 children% 可能误导你以为 main() 是热点

1
2

# 从 perf 数据生成火焰图
perf script | stackcollapse-perf.pl | flamegraph.pl > flame.svg

1
2
3
4
5
6

         ┌───────────────── func_A() ──────────────────┐
         │ ┌─── func_B() ───┐ ┌────── func_C() ──────┐│
         │ │ ┌─ func_D() ─┐ │ │ ┌─── func_E() ───┐  ││
         │ │ └─────────────┘ │ │ └─────────────────┘  ││
         │ └─────────────────┘ └──────────────────────┘│
         └─────────────────────────────────────────────┘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

#include <chrono>
#include <cstdio>

class ScopedTimer
{
public:
    explicit ScopedTimer(const char* name)
        : m_name(name)
        , m_start(std::chrono::steady_clock::now())
    {
    }

    ~ScopedTimer()
    {
        auto elapsed = std::chrono::steady_clock::now() - m_start;
        auto us = std::chrono::duration_cast<std::chrono::microseconds>(elapsed).count();
        printf("[%s] %lld us\n", m_name, static_cast<long long>(us));
    }

    ScopedTimer(const ScopedTimer&) = delete;
    ScopedTimer& operator=(const ScopedTimer&) = delete;

private:
    const char* m_name;
    std::chrono::steady_clock::time_point m_start;
};

// 使用：作用域结束时自动打印耗时
void handleRequest()
{
    ScopedTimer timer("handleRequest");
    // ... 业务逻辑 ...
}

1
2
3
4
5
6
7

# GCC/Clang 提供 -finstrument-functions 选项
# 每个函数入口/出口会自动调用：
#   __cyg_profile_func_enter(void *this_fn, void *call_site)
#   __cyg_profile_func_exit(void *this_fn, void *call_site)
g++ -finstrument-functions -g my_code.cpp -o my_program

# 你需要自己实现这两个函数来记录数据

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

#include <tracy/Tracy.hpp>

void handleRequest()
{
    ZoneScoped;  // 自动记录当前作用域
    // ... 业务逻辑 ...

    {
        ZoneScopedN("parse_headers");  // 命名子区域
        parseHeaders();
    }
}

// main 入口
int main()
{
    while (running)
    {
        FrameMark;  // 标记帧边界
        update();
        render();
    }
}

1

perf stat ./build/my_server <<< "quick_test_input"

1
2
3
4
5
6
7
8
9

 Performance counter stats for './build/my_server':

     1,234,567,890      instructions      #    1.23  insn per cycle
     1,002,345,678      cycles
        12,345,678      cache-misses      #    3.2 % of all cache refs
       385,432,100      cache-references
         5,678,901      branch-misses     #    0.5 % of all branches
     1,135,780,200      branches
             2.34 seconds time elapsed

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# 缓存分析
perf stat -e cache-references,cache-misses,\
            L1-dcache-loads,L1-dcache-load-misses,\
            LLC-loads,LLC-load-misses \
         ./build/my_program

# 分支预测分析
perf stat -e branches,branch-misses ./build/my_program

# 指令级分析（查看哪些指令类型最多）
perf stat -e instructions,cycles,\
            stalled-cycles-frontend,stalled-cycles-backend \
         ./build/my_program

1
2
3
4
5
6
7

IPC < 1.0?
├── stalled-cycles-backend 高 → Memory-bound
│   ├── LLC-miss 高 → 数据不在缓存，查数据局部性
│   └── LLC-miss 低 → L1/L2 miss 或 store buffer 满
└── stalled-cycles-frontend 高 → 指令获取慢
    ├── I-cache miss 高 → 代码体积太大（模板膨胀？）
    └── branch-miss 高 → 分支预测失败，查 if/switch 逻辑

1
2
3
4
5

# 记录所有 malloc/free 调用
heaptrack ./build/my_server

# 用 GUI 分析
heaptrack_gui heaptrack.my_server.*.gz

1
2
3
4
5

# 堆使用快照
valgrind --tool=massif --pages-as-heap=no ./build/my_program

# 文本报告
ms_print massif.out.12345

1
2
3
4

cmake -B build -DCMAKE_BUILD_TYPE=Debug \
      -DCMAKE_CXX_FLAGS="-fsanitize=address -fno-omit-frame-pointer"
cmake --build build
./build/my_program  # 泄漏在程序退出时报告

1
2
3
4
5
6
7
8

==12345==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 1024 byte(s) in 1 object(s) allocated from:
    #0 0x7f... in operator new(unsigned long) (/usr/lib/...)
    #1 0x40... in MyClass::init() (src/my_class.cpp:42)
    #2 0x40... in main (src/main.cpp:10)

SUMMARY: AddressSanitizer: 1024 byte(s) leaked in 1 allocation(s).

1

valgrind --leak-check=full --show-leak-kinds=all ./build/my_program

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

// ========================================
// Array of Structs (AoS)
// ========================================
struct Entity
{
    float x, y, z;        // 12 bytes
    float health;         // 4 bytes
    int   id;             // 4 bytes
    char  name[64];       // 64 bytes
};
// sizeof(Entity) = 88 bytes

std::vector<Entity> entities(10000);

// 遍历所有实体的 health：
for (auto& e : entities)
{
    if (e.health < 50.0f) heal(e);
}
// 每个 Entity 88B，跨 2 个 cache line（64B），读一个 health 字段要搬 2 行共 128B
// 但你只需要 health 字段（4 bytes）
// 缓存利用率：4/128 ≈ 3.1%

// ========================================
// Struct of Arrays (SoA)
// ========================================
struct Entities
{
    std::vector<float> x, y, z;
    std::vector<float> health;
    std::vector<int>   id;
    std::vector<std::array<char, 64>> name;  // 固定长度数组，保持连续
    // 注意：不要用 std::vector<std::string> 存 name——
    // std::string 是堆分配、数据不连续，会破坏 SoA 的缓存友好性
};

Entities entities;
// entities.health 是连续的 float 数组
// 遍历时每个 cache line 装 16 个 health 值
// 缓存利用率：100%

1
2

valgrind --tool=cachegrind ./build/my_program
cg_annotate cachegrind.out.12345

1
2

perf c2c record -- ./build/my_server
perf c2c report

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

// BAD：两个线程频繁写同一 cache line 的不同变量
struct Counters
{
    std::atomic<int> threadACounter;  // 偏移 0
    std::atomic<int> threadBCounter;  // 偏移 4
    // 同一个 64 字节 cache line！
    // 线程 A 写 threadACounter 时，线程 B 的缓存行被 invalidate
    // 反之亦然——两个线程在争抢一条缓存行的所有权
};

// GOOD：对齐到不同 cache line
struct Counters
{
    alignas(64) std::atomic<int> threadACounter;
    alignas(64) std::atomic<int> threadBCounter;
};

// C++17 也可以用 std::hardware_destructive_interference_size
// （MSVC 2022 / GCC 12+ / Clang 15+ 均已实现）
// 跨平台代码仍建议保留 alignas(64) 作为后备

1
2
3
4
5
6

# 生成汇编（Intel 语法，更易读）
g++ -O2 -S -masm=intel my_code.cpp -o my_code.s

# 只看某个函数的汇编
g++ -O2 -S -masm=intel my_code.cpp -o /dev/stdout | \
    sed -n '/^handleRequest/,/^[^.]/p'

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

# ==========================================
# 步骤 1：插桩编译
# ==========================================
cmake -B build-pgo-gen -DCMAKE_BUILD_TYPE=Release \
      -DCMAKE_CXX_FLAGS="-fprofile-generate=/tmp/pgo-data"
cmake --build build-pgo-gen

# ==========================================
# 步骤 2：用典型负载运行（生成 .gcda / .profraw 文件）
# ==========================================
./build-pgo-gen/my_server &
SERVER_PID=$!

# 发送真实或模拟的请求（覆盖主要路径）
wrk -t4 -c100 -d30s http://localhost:8080/
wrk -t4 -c100 -d30s http://localhost:8080/api/users
# ... 其他关键路径 ...

kill $SERVER_PID
# /tmp/pgo-data/ 下生成了 profile 数据

# ==========================================
# 步骤 3：用 profile 数据重新编译
# ==========================================
cmake -B build-pgo-use -DCMAKE_BUILD_TYPE=Release \
      -DCMAKE_CXX_FLAGS="-fprofile-use=/tmp/pgo-data"
cmake --build build-pgo-use

1
2
3

# CMake 一行开启
cmake -B build -DCMAKE_BUILD_TYPE=Release \
      -DCMAKE_INTERPROCEDURAL_OPTIMIZATION=ON

1
2
3
4
5
6
7
8
9

# Clang 编译时间追踪（生成 JSON 文件）
clang++ -ftime-trace -c heavy_template.cpp
# 生成 heavy_template.json
# 用 chrome://tracing 或 https://ui.perfetto.dev 打开

# 能看到：
# - 每个头文件的 include 耗时
# - 每个模板实例化的耗时
# - 每个函数的代码生成耗时

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

#include <benchmark/benchmark.h>
#include <vector>
#include <algorithm>
#include <random>

// ==========================================
// 基础用法
// ==========================================
static void BM_VectorPushBack(benchmark::State& state)
{
    for (auto _ : state)
    {
        std::vector<int> v;
        for (int i = 0; i < state.range(0); ++i)
        {
            v.push_back(i);
        }
        benchmark::DoNotOptimize(v.data());
    }
    state.SetComplexityN(state.range(0));
}
BENCHMARK(BM_VectorPushBack)->Range(8, 1 << 20)->Complexity();

// ==========================================
// 对比版本：预分配
// ==========================================
static void BM_VectorReserved(benchmark::State& state)
{
    for (auto _ : state)
    {
        std::vector<int> v;
        v.reserve(state.range(0));
        for (int i = 0; i < state.range(0); ++i)
        {
            v.push_back(i);
        }
        benchmark::DoNotOptimize(v.data());
    }
    state.SetComplexityN(state.range(0));
}
BENCHMARK(BM_VectorReserved)->Range(8, 1 << 20)->Complexity();

BENCHMARK_MAIN();

1
2
3
4
5
6
7
8
9

-----------------------------------------------------------
Benchmark                   Time             CPU   Iterations
-----------------------------------------------------------
BM_VectorPushBack/8        45.2 ns         45.0 ns   15534262
BM_VectorPushBack/1024     8234 ns         8215 ns      85147
BM_VectorPushBack/1048576  12.3 ms         12.2 ms         57
BM_VectorReserved/8        32.1 ns         32.0 ns   21847523
BM_VectorReserved/1024     2156 ns         2150 ns     325478
BM_VectorReserved/1048576  3.45 ms         3.44 ms        203

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

// BAD：编译器发现 result 没有被使用，直接消除整个计算
static void BM_Bad(benchmark::State& state)
{
    for (auto _ : state)
    {
        int result = expensiveComputation();
        // result 未使用 → 编译器优化掉 → 测出来 0ns
    }
}

// GOOD：用 DoNotOptimize 告诉编译器"这个值有副作用"
static void BM_Good(benchmark::State& state)
{
    for (auto _ : state)
    {
        int result = expensiveComputation();
        benchmark::DoNotOptimize(result);
    }
}

// 如果是修改了内存中的数据结构：
static void BM_InPlace(benchmark::State& state)
{
    std::vector<int> data(1024);
    for (auto _ : state)
    {
        modifyInPlace(data);
        benchmark::ClobberMemory();  // 告诉编译器"所有内存都可能被修改了"
    }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

static void BM_Sort(benchmark::State& state)
{
    std::mt19937 rng(42);
    std::uniform_int_distribution<int> dist(0, 1000000);

    for (auto _ : state)
    {
        // 暂停计时：生成随机数据不是我们要测的
        state.PauseTiming();
        std::vector<int> data(state.range(0));
        std::generate(data.begin(), data.end(), [&] { return dist(rng); });
        state.ResumeTiming();

        // 只测排序
        std::sort(data.begin(), data.end());
        benchmark::DoNotOptimize(data.data());
    }
}
BENCHMARK(BM_Sort)->Range(1024, 1 << 20);

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

static void BM_ParseJson(benchmark::State& state)
{
    std::string input = loadTestJson();  // 4KB JSON

    for (auto _ : state)
    {
        auto result = parseJson(input);
        benchmark::DoNotOptimize(result);
    }

    // 报告字节吞吐量——比纯 ns/op 更有意义
    state.SetBytesProcessed(
        static_cast<int64_t>(state.iterations()) * input.size()
    );
}
// 输出会多一列：xxx MB/s

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

#define ANKERL_NANOBENCH_IMPLEMENT
#include <nanobench.h>

int main()
{
    std::vector<int> data(10000);
    std::iota(data.begin(), data.end(), 0);

    ankerl::nanobench::Bench()
        .title("sorting algorithms")
        .relative(true)  // 第一个测试为基准，后续显示相对值
        .run("std::sort", [&]
        {
            auto copy = data;
            std::sort(copy.begin(), copy.end());
            ankerl::nanobench::doNotOptimizeAway(copy.data());
        })
        .run("std::stable_sort", [&]
        {
            auto copy = data;
            std::stable_sort(copy.begin(), copy.end());
            ankerl::nanobench::doNotOptimizeAway(copy.data());
        });
}

1
2
3
4
5

perf lock record -- ./build/my_server &
# 发送负载...
kill %1

perf lock report

1
2

# 无需重新编译，LD_PRELOAD 注入
LD_PRELOAD=/usr/lib/libmutrace.so ./build/my_server

1
2
3
4
5
6
7

mutrace: 3 mutexes used.

Mutex #0 (0x7f...) first used at src/session.cpp:42
  Locked 1,234,567 times
  Contended 23,456 times (1.9%)
  Avg wait time: 12.3 us
  Max wait time: 456.7 us

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

// BAD：整个函数加锁
std::mutex m_mutex;

void processRequest(Request& req)
{
    std::lock_guard lock(m_mutex);
    auto headers = parseHeaders(req);     // 不需要锁
    auto auth = validateAuth(headers);    // 不需要锁
    updateSessionStore(auth);             // 只有这里需要锁
    auto response = buildResponse(auth);  // 不需要锁
    sendResponse(response);              // 不需要锁
}

// GOOD：最小化临界区
void processRequest(Request& req)
{
    auto headers = parseHeaders(req);
    auto auth = validateAuth(headers);
    {
        std::lock_guard lock(m_mutex);
        updateSessionStore(auth);  // 临界区只包含必须互斥的操作
    }
    auto response = buildResponse(auth);
    sendResponse(response);
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

// BAD：用 mutex 保护一个 99% 时间在读的缓存
std::mutex m_mutex;
std::unordered_map<std::string, CacheEntry> m_cache;

CacheEntry get(const std::string& key)
{
    std::lock_guard lock(m_mutex);  // 读操作也要互斥等待
    return m_cache[key];
}

// GOOD：用 shared_mutex（读写锁）
std::shared_mutex m_rwMutex;

CacheEntry get(const std::string& key)
{
    std::shared_lock lock(m_rwMutex);  // 多个读者可以同时进入
    auto it = m_cache.find(key);
    return it != m_cache.end() ? it->second : CacheEntry{};
}

void set(const std::string& key, CacheEntry value)
{
    std::unique_lock lock(m_rwMutex);  // 写者独占
    m_cache[key] = std::move(value);
}

> **注意**：`shared_mutex` 内部状态比 `mutex` 复杂，`shared_lock` 的获取开销也更高。当临界区很小（< 100ns 的简单操作）时，读写锁往往**比** `std::mutex` 更慢。用之前务必用 Benchmark 实测，不要盲信"读写锁一定更快"。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

// BAD：每次请求都原子递增全局计数器
std::atomic<uint64_t> g_totalRequests{0};

void handleRequest()
{
    g_totalRequests.fetch_add(1, std::memory_order_seq_cst);
    // seq_cst 是最强的内存序，会产生内存屏障（mfence）
}

// GOOD：用宽松内存序（如果只是统计，不需要和其他操作同步）
void handleRequest()
{
    g_totalRequests.fetch_add(1, std::memory_order_relaxed);
    // relaxed 只要求编译器不额外插入屏障指令；
    // 但 x86 的原子 RMW 指令（lock add）本身隐含硬件级的内存排序
    // 真正"无同步"的原子操作只有 relaxed 的 load/store
}

// BETTER：线程局部累积 + 定期汇总（完全无竞争）
thread_local uint64_t tLocalCount = 0;

void handleRequest()
{
    ++tLocalCount;  // 无原子操作，纯寄存器操作
}

// 定期汇总（比如每秒一次）
uint64_t collectTotal()
{
    // 遍历所有线程的 thread_local 累加
}

1
2
3
4

cmake -B build -DCMAKE_BUILD_TYPE=Debug \
      -DCMAKE_CXX_FLAGS="-fsanitize=thread"
cmake --build build
./build/my_program

1
2
3
4
5
6

WARNING: ThreadSanitizer: data race (pid=12345)
  Write of size 4 at 0x7f... by thread T2:
    #0 MyClass::update() src/my_class.cpp:67

  Previous read of size 4 at 0x7f... by thread T1:
    #0 MyClass::getValue() src/my_class.cpp:23

1
2
3
4
5
6
7
8
9

# ASan + UBSan：可以同时开启（推荐组合）
cmake -DCMAKE_CXX_FLAGS="-fsanitize=address,undefined -fno-omit-frame-pointer"

# TSan：必须单独使用（和 ASan 冲突）
cmake -DCMAKE_CXX_FLAGS="-fsanitize=thread"

# MSan：必须单独使用，且所有依赖库也要用 MSan 编译
# （实际操作中很难满足，通常只在特定场景使用）
cmake -DCMAKE_CXX_FLAGS="-fsanitize=memory"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# 典型的 CI 矩阵
jobs:
  build-release:
    # 正常 Release 编译 + 测试
    cmake -DCMAKE_BUILD_TYPE=Release

  build-asan:
    # ASan + UBSan 检测内存错误和未定义行为
    cmake -DCMAKE_BUILD_TYPE=Debug \
          -DCMAKE_CXX_FLAGS="-fsanitize=address,undefined -fno-omit-frame-pointer"

  build-tsan:
    # TSan 检测数据竞争（单独一个 job）
    cmake -DCMAKE_BUILD_TYPE=Debug \
          -DCMAKE_CXX_FLAGS="-fsanitize=thread"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

□ 1. 有量测数据证明这是瓶颈吗？
     如果没有 → 不要优化。最常见的浪费就是优化不是瓶颈的代码

□ 2. 算法复杂度对吗？
     O(N²) → O(N log N) 的收益，比任何微优化大 100 倍
     先看大 O，再看常数因子

□ 3. 有没有不必要的内存分配？
     string 拷贝、临时对象、容器 realloc
     用 Heaptrack 看一个请求分配了多少次

□ 4. 数据布局是否缓存友好？
     热数据 / 冷数据分离了吗？遍历模式和内存布局匹配吗？
     IPC < 1.0 且 cache-miss 高 → 改数据布局

□ 5. 有没有不必要的同步？
     锁粒度是否最小？原子操作的内存序是否过强？
     能否用 thread_local 消除竞争？

□ 6. 编译器能帮你吗？
     PGO 试了吗？LTO 开了吗？-O2 了吗？
     这些是免费的性能（只需要改构建配置）

□ 7. I/O 模式对吗？
     批量 vs 逐条？异步 vs 同步？
     批量写：POSIX `writev` / Windows `WSASend`（scatter/gather）
     零拷贝：POSIX `sendfile`/`splice` / Windows `TransmitFile`

□ 8. DB / 存储访问对吗？
     循环里逐条 SELECT 是不是 ODB lazy loading 触发的 N+1？
     查询能否批量 / 合并？连接池是否过小导致排队等待？
     慢查询有没有走 MySQL slow query log 定位？

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

┌──────────────────────────────────────────────┐
│  1. 架构级（最大收益，最早做）                    │
│     - 同步 → 异步                                │
│     - 单线程 → 多线程（或反过来减少锁）            │
│     - 网络往返减少（批量/缓存/CDN）               │
├──────────────────────────────────────────────┤
│  2. 算法级                                      │
│     - O(N²) → O(N log N) → O(1)               │
│     - 选择更合适的数据结构                        │
├──────────────────────────────────────────────┤
│  3. 数据级                                      │
│     - 缓存友好的内存布局（SoA、热冷分离）          │
│     - 减少堆分配（pool、stack alloc）             │
│     - 零拷贝                                     │
├──────────────────────────────────────────────┤
│  4. 编译器级（免费的午餐）                        │
│     - 优化级别（-O2/-O3）                        │
│     - PGO / LTO                                 │
│     - constexpr 计算下推到编译期                  │
├──────────────────────────────────────────────┤
│  5. 微优化级（最后才做，收益最小）                 │
│     - branchless 写法                           │
│     - SIMD 手写向量化                            │
│     - cache line 对齐                           │
│     - 汇编级调优                                 │
└──────────────────────────────────────────────┘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

需要分析什么？（Linux / Windows 双平台）
│
├── CPU 热点在哪？
│   ├── Linux     → perf record + 火焰图
│   ├── Windows   → Visual Studio Profiler / ETW + WPA / VTune
│   └── 跨平台    → Tracy（游戏行业标配，实时可视化）
│
├── 内存分配合理吗？
│   ├── Linux     → Heaptrack（分配热点）/ Massif（峰值快照）
│   ├── Windows   → UMDH（堆分配追踪）/ WPA Heap Analysis / VS 内存快照
│   └── 泄漏检测  → ASan（推荐，双平台）/ Valgrind memcheck（Linux 备选）
│
├── 缓存命中率如何？
│   ├── 真实硬件  → perf stat / VTune（Linux）| ETW PMC + WPA（Windows）
│   └── 模拟分析  → Cachegrind（双平台，极慢，适合小程序）
│
├── 有数据竞争吗？
│   ├── Linux     → TSan（唯一靠谱的运行时检测方案）
│   └── Windows   → Intel Inspector / Dr. Memory（MSVC 不支持 TSan）
│
├── 锁竞争严重吗？
│   ├── Linux     → perf lock / Mutrace
│   └── Windows   → ETW + WPA（Contention Analysis）/ Intel Inspector
│
├── 有未定义行为吗？
│   ├── Linux     → UBSan（推荐）
│   ├── Windows   → MSVC `/RTC1` 部分替代 / Clang-cl + UBSan
│   └── 通用      → MSVC `/analyze` 静态分析
│
├── 编译太慢？
│   ├── Clang     → `-ftime-trace`（每个模板实例化耗时一目了然）
│   └── MSVC      → `/d1reportTime`（头文件 include 耗时）/ `/d2cgsummary`（后端优化耗时）/ `/Bt+`（各函数编译耗时）
│
├── Lua 性能问题？
│   └── 通用      → debug.sethook 采样 / lua_setallocf 分配跟踪 / GC 停顿分析（详见第十一章）
│
└── 生产环境持续监控？
    ├── Linux     → eBPF / bcc / bpftrace
    └── Windows   → ETW Kernel Trace（WPR + WPA，轻量可常驻）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 1. 用 WPR UI 或 CLI 录制（建议 WPR UI 选择 "CPU usage" + "File I/O" Profile）
wpr -start cpu -start fileio

# 2. 运行负载（如游戏压测）
.\ZoneServer_c.exe

# 3. 停止录制
wpr -stop perf_trace.etl

# 4. 用 WPA 打开 .etl 文件分析
wpa.exe perf_trace.etl

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

REM 启用栈回溯（需要管理员权限）
gflags /i ZoneServer_c.exe +ust

REM 运行服务器，取两个快照（前后对比）
umdh -p:<PID> -f:snapshot1.txt
REM ...执行一段业务逻辑...
umdh -p:<PID> -f:snapshot2.txt

REM 对比两个快照，看增量分配
umdh snapshot1.txt snapshot2.txt > diff.txt

1
2
3
4
5
6
7
8
9

REM 用 xperf（Windows 7/8 SDK）捕获 IOCP 事件
xperf -start IoctlSession -on PROC_THREAD+LOADER+DISK_IO+NETWORK -f iocp.etl
REM 运行负载...
xperf -stop IoctlSession

REM 用 WPA 打开 iocp.etl，关注：
REM - "Thread" Graph：看工作线程是 Running 还是 Waiting
REM - "DPC/ISR"：网络中断是否过于频繁
REM - "Disk I/O"：DB 写入是否变成了瓶颈

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# Step 1: 插桩编译
cmake -B build-pgo -DCMAKE_BUILD_TYPE=Release `
    -DCMAKE_CXX_FLAGS="/GL /LTCG:PGINSTRUMENT"

# Step 2: 运行典型负载，产生 .pgc 文件
./build-pgo/ZoneServer_c.exe

# Step 3: 用 Profile 数据优化编译
cmake -B build-pgo-opt -DCMAKE_BUILD_TYPE=Release `
    -DCMAKE_CXX_FLAGS="/GL /LTCG:PGOPTIMIZE /USEPROFILE"

1
2
3
4
5
6
7
8
9

# 启动最小开销的内核级 CPU Profile（~1-2% 开销）
wpr -start CPU -start DiskIO -start FileIO

# 运行服务器，正常处理业务...

# 积累半小时后 dump
wpr -stop weekly_trace_$(Get-Date -Format yyyyMMdd_HHmm).etl

# 下次继续

1
2
3
4
5

# 在 Linux 上检查整体指标
perf stat -p $(pgrep ZoneServer) -- sleep 30

# 如果 IPC < 1.0 或 LLC miss > 5%，说明 Windows 上没暴露出来的
# 数据局部性问题在 Linux 大核上被放大了

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

-- 最简单的按行采样器（示例骨架）
local samples = {}
local depth = 0

local function hook()
    depth = depth + 1
    if depth % 100 == 0 then            -- 每 100 行采一次样
        local info = debug.getinfo(2, "Sln")
        if info then
            local key = (info.source or "?") .. ":" .. (info.currentline or "?")
            samples[key] = (samples[key] or 0) + 1
        end
    end
end

debug.sethook(hook, "l")               -- "l" = 每执行一行调用一次

-- 运行被测业务 ...
runRealWorkload()

debug.sethook()                          -- 结束采样

1
2
3
4
5
6
7
8
9

// C++ 侧注入分配器（示意）
static void* my_alloc(void* ud, void* ptr, size_t osize, size_t nsize)
{
    if (nsize == 0) { /* free */ }
    else if (ptr == nullptr) { /* malloc，累计 bytes_allocated += nsize */ }
    else { /* realloc，累计 bytes_allocated += (nsize - osize) */ }
    return realloc(ptr, nsize);   // 示例：实际应转发给真实分配器
}
lua_setallocf(L, my_alloc, nullptr);

1
2

print(collectgarbage("count"))          -- 当前 KB 数，看内存水位
print(collectgarbage("incremental", "step", 1024 * 1024))  -- 强制单步，观察耗时

1
2
3
4
5
6

-- 用 os.clock 粗测
local t0 = os.clock()
for i = 1, 1000000 do
    obj:GetLevel()      -- 被测的跨边界调用
end
print(os.clock() - t0)