
## 结论先行

307MB 向量索引（10 万条 × 768 维 float32），三种加载方式在本机实测：

- **映射只要 0.19~0.23ms，读进堆要 26.6~27.6ms**，差 130 倍。但这个 0.19ms 是假的——它只是建了页表，一个字节都没读。
- **mmap 不省内存。** 全量扫一遍后，RSS 都是 356MB，和 `File.ReadAllBytes` 的 354MB 没有区别。它省的只是「托管堆里那 293MB」，页最终还是要进物理内存。
- **稀疏随机访问会放大 RSS 4.7 倍。** 随机摸 1 万条向量（有效数据 30MB），mmap 的 RSS 从 54MB 涨到 196MB——多出来的 142MB 是预读和页粒度带来的。
- **单点冷访问贵 1.8 倍。** mmap 每次约 1µs（缺页中断），已在内存里的数组 542ns。热起来之后两者都是 250ns，完全一样。
- **只扫一次的场景，mmap 反而快 31%**：端到端 50.0ms vs 72.0ms。省的不是 IO，是那次 293MB 的拷贝和清零。

短结论：mmap 换来的是「启动快」和「堆外存储」，代价是「首次访问的缺页税」和「RSS 不可预测」。它不是零拷贝银弹。

## 实验设置

- 机器：Apple M4 / 10 核 / macOS arm64 / 32GB，.NET 10.0.5，Release。
- 数据：`vectors.f32`，100,000 × 768 × 4B = 307,200,000 B（293 MiB），值域 [-1,1)。
- 三种方式，跑同一条计算路径（同一份点积实现，SIMD 选型不是本文主题）：
  1. `mmap`：`MemoryMappedFile.CreateFromFile` + `CreateViewAccessor`，`AcquirePointer` 后包成 `ReadOnlySpan<float>`。
  2. `bytes`：`File.ReadAllBytes` + `MemoryMarshal.Cast<byte,float>`。
  3. `chunk`：预分配 `GC.AllocateUninitializedArray<float>(7680 万)`，4MB 一块读进它的字节视图。
- 三种方式是三个独立进程，否则 RSS 互相污染。
- RSS 用外部 `ps -o rss= -p <pid>` 读，不在进程内估。
- 每个进程：先 1 万次随机向量点积（冷 pass），同样 1 万次再跑一遍（热 pass），再全量扫 3 轮记 top-10。
- 计时用 `Stopwatch.GetTimestamp`，测得计时器本身开销 7.5~7.9ns。
- 关键细节：点积方法要在**不触碰映射页**的前提下预热 JIT（用一个小数组跑一次），否则第一次探针会把 JIT 的 450µs 记进「冷访问」。

## 映射不等于加载：0.19 毫秒是假的

| 方式 | 加载耗时 | 加载时分配 |
| --- | --- | --- |
| mmap | **0.19~0.23ms** | **0.0MB** |
| bytes | 26.6~26.8ms | 293.0MB |
| chunk | 26.6~27.6ms | 293.0MB |

`CreateFromFile` + `CreateViewAccessor` 只做了两件事：建虚拟地址映射、拿到基址。0 字节数据被读入。

RSS 立刻能看出这件事：映射建完，RSS 从 43MB 只涨到 54MB——涨的 11MB 是 view 结构本身，不是数据。

所以「mmap 加载快 130 倍」这句话没有意义。真正要看的是**第一次访问**什么时候付钱。

## 三种方式的内存账单：RSS 最后一样多

| 阶段 | mmap | bytes | chunk |
| --- | --- | --- | --- |
| 映射/读取后 | 54.2MB | 354.4MB | 354.4MB |
| 1 万次随机访问后 | 196.1MB | 354.9MB | 355.0MB |
| 全量扫一遍后 | 356.3MB | 356.5MB | 356.5MB |

跑完整个流程，三者 RSS 差异在 0.2MB 以内。

这是最容易被误解的一点：mmap 的「省内存」只在**你没把它读全**的时候成立。一旦全扫，干净页也全部驻留，RSS 一样顶到 356MB。

mmap 真正换来的是另外两样东西，都跟 RSS 数字无关：

1. **数据不在托管堆里。** 293MB 的 `byte[]` 会直接进 LOH，之后每次 gen2 GC 都要扫到它；映射页对 GC 完全透明。
2. **干净页可以被内核回收。** 这一点我没法在 Mac 上稳定复现（需要制造内存压力），只按机制说明，不算实测结论。

## 稀疏随机访问会把 RSS 放大 4.7 倍

上面那张表里最刺眼的一行：随机摸 1 万条向量，有效数据只有 1 万 × 3072B = **30MB**，但 RSS 涨了 **142MB**。

原因不是我的代码读多了——是内核的页粒度 + 预读：每条向量 3072B 天然跨 2 个 16KB 页，而文件页的预读策略会顺手把邻居也拉进来。稀疏采样落在 307MB 的地址空间上，几乎每个探针都命中一个「没被摸过的页组」。

结论：**mmap 的 RSS 增长速度不由「你读了多少字节」决定，而由「你碰了多少页」决定。** 随机访问索引的场景，按 RSS 上限做容量规划会算错。

## 单点访问：1µs 的缺页税

1 万次随机向量点积，单次耗时（已扣除 7.5ns 计时开销）：

| 方式 | 冷 p50 | 冷 p95 | 冷 p99 | 冷 max | 热 p50 |
| --- | --- | --- | --- | --- | --- |
| mmap | 959~1000ns | 1500ns | 1667~1708ns | 7.5~9.1µs | 250ns |
| bytes | 542ns | 667~708ns | 916~1000ns | 1.5µs | 250ns |
| chunk | 542ns | 667~708ns | 916~1000ns | 1.6µs | 250ns |

- mmap 冷访问比已在内存的数组慢 **1.8 倍**，每次多的那 ~450ns 就是缺页中断 + 页表填充。
- 热 pass 三者都是 **250ns**：一旦页都驻留，mmap 的访问路径和普通指针没有任何差别。这是 mmap「热了之后零成本」的最直接证据。
- 冷 max 8µs 不是异常：那是撞上一次批量 page-in 的极端样本。

所以「mmap 适合随机访问」这句要加限定：**只在页已经热的情况下成立。** 冷启动阶段每碰一条向量要付一次缺页。

## 全扫：首轮多付 6ms，稳态完全打平

10 万条向量与同一查询做点积，取 top-10：

| 方式 | 第 1 轮 | 第 2 轮 | 第 3 轮 |
| --- | --- | --- | --- |
| mmap | 49.6~49.9ms | 43.7~44.1ms | 44.1~45.2ms |
| bytes | 45.2~45.4ms | 43.2~45.5ms | 42.8~43.8ms |
| chunk | 45.1~47.1ms | 45.0~45.2ms | 43.7~53.7ms |

- mmap 第一轮比稳态多 **5.7~6.2ms**，这就是 307MB 全量缺页的账单，摊到 10 万条上约 **60ns/条**。
- 稳态三轮，三者落在同一区间（42.8~45.5ms），差异在噪声内。**热了以后 mmap 不快也不慢。**
- chunk 第 3 轮出现 53.7ms 的离群，属系统调度噪声，不影响结论。

注意这里 mmap 的缺页成本（6ms）远小于 bytes 的读取成本（27ms）。差额就是「内核页缓存 → 用户空间那一份拷贝 + 大对象清零」。这解释了下一节。

## 端到端账：只扫一次，mmap 反而省 22ms

把「打开到出结果」算在一起：

| 方式 | 加载 | 首次全扫 | 合计 |
| --- | --- | --- | --- |
| mmap | 0.2ms | 49.8ms | **50.0ms** |
| bytes | 26.7ms | 45.3ms | 72.0ms |
| chunk | 27.0ms | 46.1ms | 73.1ms |

**mmap 快 31%（50.0ms vs 72.0ms）。**

省下来的 22ms 不是「IO 更快」，而是**根本不做那次 307MB 的 memcpy**——数据原地待在页缓存里，缺页时只建立映射，计算直接读内核页。

反过来看：如果你是「加载一次、反复查询几百次」的常驻服务，这 22ms 只付一次，可以忽略；这时候选哪个，看的是内存形态（堆内 293MB 大对象 vs 堆外页），不是速度。

## 什么时候该用 mmap

- **用**：索引文件大于可用内存、且只访问其中一部分（冷热分层）；进程启动要快、首屏不能等 27ms 加载；索引在托管堆里会撑爆 LOH 或拉长 GC 暂停。
- **不用**：加载后就要全量常驻（RSS 一样，白搭一层复杂度）；对单次访问延迟敏感且页是冷的（每条多 450ns）；需要跨平台稳定行为（Windows 的文件映射语义、删除/截断行为都和 macOS 不同）。
- **谨慎**：用 RSS 做容量规划。按页算，不按字节算。

## 可复现步骤

```bash
# .NET 10.0.5，Release，macOS arm64
dotnet build -c Release
./bin/Release/net10.0/MmapLab gen      # 生成 307,200,000 B 的 vectors.f32
for m in mmap bytes chunk; do ./bin/Release/net10.0/MmapLab $m; done
```

程序里三个要点：

```csharp
// 1) 建映射（0 字节数据被读入）
using var mmf = MemoryMappedFile.CreateFromFile("vectors.f32", FileMode.Open, null, 0, MemoryMappedFileAccess.Read);
using var acc = mmf.CreateViewAccessor(0, 0, MemoryMappedFileAccess.Read);
byte* p = null;
acc.SafeMemoryMappedViewHandle.AcquirePointer(ref p);
p += acc.PointerOffset;                       // 必须加，否则偏移错
var span = new ReadOnlySpan<float>(p, 100_000 * 768);
// ... 用完后 acc.SafeMemoryMappedViewHandle.ReleasePointer();

// 2) 预热 JIT 但不碰映射页，否则冷测量被 450µs 的 JIT 污染
sink += Dot(warmBuffer, query);

// 3) RSS 用外部 ps 读，别在进程内估
ps -o rss= -p <pid>
```

## 三个坑

1. **`PointerOffset` 不能省。** view 的基址不一定是页对齐映射的起点，漏加会从头 0 偏移读，数据错但不报错，最坏情况是 top-1 结果对了、分数错了。
2. **冷测量前别用真数据预热。** 用真数据跑一次 `Dot` 图省事，会把整段映射页拉进来，冷 pass 直接变成热 pass，结论会从「1.8 倍」变成「1.0 倍」。
3. **`File.ReadAllBytes` 的首轮不稳定。** 同机同文件，我见到过 26.7ms 和 42.2ms 两种结果（后者是首次运行）。报单个数字容易失真，按区间报更诚实。

---

测试环境：.NET 10.0.5 / Apple M4（10 核）/ macOS arm64 / 32GB。所有数字为本机实测，两轮独立进程复现，未引用他人测量值。文件页缓存在测量时是热的（文件刚写完），所以本文测的是「映射与缺页」成本，不含真实磁盘 IO——真冷启动还要再加一次 307MB 的顺序读。


307MB 向量索引（10 万条 × 768 维 float32），三种加载方式在本机实测：

MemoryMappedFile 加载 307MB 向量索引实测：映射只要 0.19 毫秒，但省下的内存最后都要还

编程语言

操作系统

后端

mmap加载307MB索引仅需0.19ms，比读入堆快130倍，但首轮全量扫描慢6ms，端到端反而快31%（50ms vs 72ms）。mmap省的是启动时间和堆内存，代价是冷访问1.8倍延迟及RSS按页增长。热态下与常规数组无性能差异，适合冷热分层或快速启动场景。

代码解释

Windows

MacOS

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

MemoryMappedFile 加载 307MB 向量索引实测：映射只要 0.19 毫秒，但省下的内存最后都要还-腾讯云开发者社区-腾讯云

MemoryMappedFile 加载 307MB 向量索引实测：映射只要 0.19 毫秒，但省下的内存最后都要还

MemoryMappedFile 加载 307MB 向量索引实测：映射只要 0.19 毫秒，但省下的内存最后都要还

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐