背景 很多后台系统首屏不慢，但页面切换时常有明显等待。通常是路由组件和数据都在点击后才加载。 实用做法 鼠标悬停时预取路由 chunk 关键列表页预取首屏数据 低网速场景要可降级关闭 const UserPage = () => import('@/pages/UserPage.vue') function prefetchUserPage() { void UserPage() } 总结 预取策略要适度，目标是减少等待感，不是盲目预加载所有页面。 用户感知速度，很多时候来自“提前一步”。
背景 很多 allocator 优化在 micro benchmark 里很好看，上线却收益一般。原因是评测维度不完整。 建议指标 p50/p95/p99 分配耗时 长时间运行碎片率 多线程争用下吞吐波动 auto begin = std::chrono::steady_clock::now(); void* p = alloc.allocate(256); alloc.deallocate(p, 256); auto end = std::chrono::steady_clock::now(); 总结 评测方法比结果数值更重要，先保证实验可信，再比较方案优劣。 性能数据要能解释真实场景，才有决策价值。
为什么“打开 O3”还不够 大型 C++ 服务的热点跨模块分散，单文件优化难以奏效。LTO 能打通跨 TU 优化，PGO 能把优化预算聚焦在真实热路径。 推荐流程 基线版本：记录 p50/p99、CPU、指令数、缓存 miss。 LTO 版本：先验证链接时间与二进制体积变化。 PGO 训练：必须使用“接近线上”的请求分布。 组合验证：LTO + PGO 与基线做 A/B。 CMake 关键配置示例 # LTO set(CMAKE_INTERPROCEDURAL_OPTIMIZATION ON) # PGO 两阶段 # 1) -fprofile-generate # 2) -fprofile-use -fprofile-correction 最常见的误区 用单一压测脚本训练 PGO，导致优化偏科。 只看吞吐，不看长尾延迟和抖动。 忽略符号变化对排障工具链（perf、addr2line）的影响。 回归防线 增加“训练集漂移”检测：训练流量和线上流量偏差超阈值就拒绝发布。 将“优化收益”拆解到函数级，防止偶然抖动误判。 为 PGO 单独维护回退开关和构建产物。 小结 LTO/PGO 是生产力工具，不是玄学加速按钮。只有接入真实流量画像和回归防线，优化收益才可持续。
背景 不是所有性能优化都要上自研内存池。很多时候，std::pmr 已经能解决不少问题。 一个实用场景 请求处理阶段会构建很多临时字符串和容器，生命周期一致，适合放在同一块内存资源里。 #include <memory_resource> #include <string> #include <vector> void handleRequest() { std::byte buffer[4096]; std::pmr::monotonic_buffer_resource pool(buffer, sizeof(buffer)); std::pmr::vector<std::pmr::string> fields{&pool}; fields.emplace_back("user", &pool); fields.emplace_back("email", &pool); } 总结 pmr 的价值在于“低侵入地控制分配策略”。 在临时对象密集场景里，收益通常比预想更明显。 能用标准库解决的问题，优先别把复杂度推到自研。
背景 很多集群的问题，最后都落在资源配置上： requests 太高，调度不进去 requests 太低，服务被抢占导致抖动 limits 太严，CPU 被频繁 throttling 基本策略 先测业务基线，再填 requests CPU limits 结合业务特性决定是否设置 内存 limits 必须有，否则容易把节点拖垮 resources: requests: cpu: "300m" memory: "512Mi" limits: cpu: "1000m" memory: "1Gi" 观测指标 建议持续看： container_cpu_cfs_throttled_seconds_total container_memory_working_set_bytes Pod OOMKilled 次数 总结 资源参数不是一次性配置，而是持续调优过程。 用监控数据驱动参数调整，比凭经验拍数值更靠谱。 资源治理本质是容量治理，最终影响的是可用性和成本。
先明确目标 “零拷贝”不是为了炫技，而是为了减少： 内存分配次数 数据复制成本 GC 或 allocator 压力 在高吞吐场景里，收益通常很直接。 借用驱动的数据视图 Rust 的借用模型天然适合做零拷贝读取： #[derive(Debug)] struct Header<'a> { trace_id: &'a str, method: &'a str, } fn parse_header<'a>(trace_id: &'a str, method: &'a str) -> Header<'a> { Header { trace_id, method } } 这里没有分配新字符串，只是借用了输入切片。 适用边界 适合： 协议解析 日志处理 消息中间件消费链路 不适合： 需要长期持有数据跨线程传递 接口边界复杂，生命周期管理成本过高 工程上的折中 热路径零拷贝 冷路径允许复制换可读性 用基准测试验证收益，而不是主观判断 小结 零拷贝是性能工具，不是教条。只有在瓶颈路径上，它才是值得支付复杂度的优化。
先问一个问题 同样是 O(n)，为什么有的循环快很多？ 答案常常不在算法复杂度，而在 CPU cache 命中率。现代 CPU 的瓶颈常常是内存访问，不是算术指令。 AoS 与 SoA 常见结构： struct Particle { float x, y, z; float vx, vy, vz; int alive; }; std::vector<Particle> particles; 如果你只更新位置，实际上每次还会把速度和状态也加载进缓存。更好的方式是 SoA： struct Particles { std::vector<float> x, y, z; std::vector<float> vx, vy, vz; std::vector<int> alive; }; 这样 CPU 读取的数据更“纯”，预取更有效。 减少伪共享 多线程里，两个线程写不同变量也可能互相拖慢，因为它们落在同一 cache line。 struct alignas(64) Counter { std::atomic<uint64_t> value; }; 用对齐把热点写入隔离开，通常能明显降低抖动。 少做指针追逐 链表、树这类结构在理论上优雅，但在缓存层面很吃亏。工程上更常见的折中是： 用连续数组表示节点池 索引代替裸指针 批量遍历而不是随机跳转 实践建议 先用 profiler 看 cache miss，再改代码 热路径优先考虑连续内存 把“数据怎么放”当成接口设计的一部分 小结 性能优化不是玄学。对于 C++，缓存友好的数据布局往往比微观语法技巧更值回票价。
背景 写 C++ 服务或者引擎代码时，经常会碰到一种情况：CPU 看着不高，但延迟就是压不下去。 最后一 profile，热点不在算法，也不在锁，而是在 operator new 和 operator delete。 这类问题在下面几种场景里尤其常见： 网络服务里大量创建短生命周期请求对象 游戏引擎里频繁分配小型组件 消息队列消费者持续构造临时 buffer 如果对象大小固定，或者分布相对集中，内存池通常是很直接的一刀。 为什么默认分配器会成为瓶颈 通用分配器要解决的问题很多： 不同尺寸的内存申请 跨线程竞争 碎片整理 对齐要求 这些能力都很重要，但它们也意味着额外开销。 如果你的场景很单一，比如“每次都申请一个 256 字节的请求对象”，那继续走通用分配器其实是在为用不到的能力买单。 一个简单的固定块内存池 先看一个足够说明问题的版本。 #include <cstddef> #include <new> #include <vector> class MemoryPool { public: MemoryPool(std::size_t blockSize, std::size_t blockCount) : block_size_(blockSize) { data_.resize(blockSize * blockCount); for (std::size_t i = 0; i < blockCount; ++i) { void* ptr = data_.data() + i * blockSize; free_list_.push_back(ptr); } } void* allocate() { if (free_list_.empty()) { throw std::bad_alloc(); } void* ptr = free_list_.back(); free_list_.pop_back(); return ptr; } void deallocate(void* ptr) { free_list_.push_back(ptr); } private: std::size_t block_size_; std::vector<char> data_; std::vector<void*> free_list_; }; 思路很直接： ...
背景 只要做过高并发服务、游戏引擎或者低延迟组件，迟早会碰到一个问题：锁太重了。 典型场景包括： 生产者线程持续推消息 消费者线程高频拉取任务 临界区很短，但锁竞争很激烈 延迟指标对尾部抖动非常敏感 这时候很多人第一反应是“上无锁队列”。 方向没错，但无锁代码最危险的地方在于：看起来能跑，不代表一定正确。 尤其在 C++ 里，只会用 compare_exchange_weak 还不够，真正决定正确性的往往是内存序。 无锁不等于没有同步 先澄清一个常见误区： mutex 是同步 原子变量也是同步 无锁结构只是把同步方式从“阻塞锁”换成了“原子操作 + 内存可见性约束”。 也就是说，你不是不需要同步了，而是需要更精确地控制同步。 一个最简单的 SPSC 环形队列 先从单生产者、单消费者模型说起。这个模型更适合作为理解内存序的起点。 #include <atomic> #include <array> #include <cstddef> template <typename T, std::size_t N> class SpscQueue { public: bool push(const T& value) { const auto tail = tail_.load(std::memory_order_relaxed); const auto next = (tail + 1) % N; if (next == head_.load(std::memory_order_acquire)) { return false; } buffer_[tail] = value; tail_.store(next, std::memory_order_release); return true; } bool pop(T& value) { const auto head = head_.load(std::memory_order_relaxed); if (head == tail_.load(std::memory_order_acquire)) { return false; } value = buffer_[head]; head_.store((head + 1) % N, std::memory_order_release); return true; } private: std::array<T, N> buffer_{}; std::atomic<std::size_t> head_{0}; std::atomic<std::size_t> tail_{0}; }; 这个实现不复杂，但已经体现了两个关键点： ...
背景 前端性能这件事，经常有两个极端： 一种是完全不管，页面卡了再说 另一种是上来就讲虚拟列表、SSR、代码分割，结果项目里真正拖慢页面的点根本不在那 Vue3 本身已经做了不少优化，但框架快，不代表业务代码就一定快。 真正影响体验的，通常还是这些问题： 不必要的响应式开销 大列表重复渲染 首屏加载资源过大 watch 写得太随意，副作用失控 这篇文章只聊实战里最常见、最值回票价的优化点。 先判断瓶颈在哪 优化前先确认问题类型。通常分三类： 首屏慢 JS 包太大、资源太多、接口太慢。 交互卡 某个状态变更引起大面积重渲染。 长列表卡 DOM 数量过多，滚动和 patch 开销都很高。 这三类问题的解决手段完全不同。不要把“页面卡”都归因到 Vue 响应式。 不要把所有东西都塞进 reactive 很多项目里常见这种写法： const state = reactive({ tableData: [], chartInstance: null, editor: null, wsConnection: null, filters: { keyword: '', status: 'all', }, }) 看起来统一，实际上问题不少。 像图表实例、编辑器对象、WebSocket 连接这种第三方对象，本来就不是拿来做细粒度响应式追踪的。把它们塞进深层响应式对象里，只会增加代理成本，还可能带来奇怪副作用。 更合理的拆法是： import { reactive, shallowRef, markRaw } from 'vue' const filters = reactive({ keyword: '', status: 'all', }) const tableData = shallowRef<User[]>([]) const chartInstance = shallowRef<any>(null) const editor = shallowRef<any>(null) function initChart(el: HTMLDivElement) { chartInstance.value = markRaw(createChart(el)) } 这里的思路很明确： 业务表单状态，用 reactive 大数组、外部实例，用 shallowRef 不希望被代理的对象，用 markRaw 这不是“写法偏好”，而是直接影响更新成本。 ...