pytorch中tensor[mask]、tensor[index_list]等操作变慢，是因为触发了高级索引（advanced indexing），默认返回副本而非视图，需分配新内存、重建tensorimpl、解析逻辑并跳址拷贝数据；首次调用尤其卡顿，后续仅因缓存掩盖结构性开销。
tensor[mask]、tensor[index_list] 这类操作变慢，不是因为数据量大，而是它们触发了 **advanced indexing（高级索引）**，默认返回副本而非视图——每次都要分配新内存、重建 TensorImpl、解析逻辑、跳着寻址拷贝数据。首次调用尤其卡顿，后续快只是缓存掩盖了结构性开销。
哪些索引会悄悄变成高级索引？
只要出现以下任意一种，就进入高开销路径：
-
tensor[tensor > 0.5]（布尔张量） -
tensor[[0, 2, 5]]或tensor[indices]（indices.dtype == torch.long） -
tensor[mask, :]（混合索引，任一维度用了上两类）
tensor[10:100]、tensor[::2, ...]、tensor[None, :] 属于 basic indexing，零拷贝、极快——别误把切片当慢操作归因。
为什么第一次特别慢，后面却快了？
首次执行要完成四件事：① 分配新张量内存；② 解析掩码/索引逻辑；③ 构造完整的 TensorImpl（含 stride、storage 指针、device info 等 C++ 对象）；④ 遍历原始张量做条件寻址并拷贝。其中第③步构造/析构开销极大，且无法被 JIT 完全消除。
后续调用快，是因为部分中间状态（如 kernel 缓存、TensorImpl 模板）被复用，但底层仍需拷贝数据、访存不连续——nvprof 会看到大量小 kernel launch 和高 L2 cache miss。
怎么避免或缓解？
优先用语义明确、底层优化过的算子替代直写索引：
- 单维整数索引 → 改用
torch.index_select(input, dim, index)（比input[index]更稳定、更易被编译器优化） - 多维 gather → 用
torch.gather，避免tensor[i, j]类混合高级索引 - 布尔筛选 → 若 mask 复用频繁，先用
torch.nonzero(mask, as_tuple=True)提前拿到坐标，再用index_select或gather - 循环中索引 → 绝对不要写
for i in indices: out[i] = x[i]；改用预分配 +index_put_原地填充
注意：torch.compile 对高级索引优化有限——它能融合后续计算，但无法绕过索引本身的拷贝逻辑。
连续性（contiguous）会让索引更慢吗？
不会直接让索引变慢，但会放大高级索引的代价。非连续张量（如转置后未 .contiguous()）在 torch.index_select 或 masked_select 中仍需先按 stride 跳着读，进一步降低访存效率。基础切片（如 x[:, 5]）对非连续张量也安全，但一旦混入高级索引（如 x[mask, 5]），就会双重恶化：既要跳着读原始数据，又要拷贝到新内存。
真正该检查的不是“张量是否连续”，而是“你写的这行索引，是不是高级索引”。很多性能问题根源不在数据布局，而在索引写法本身。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
