8.1 计算性能优化

8.1 计算性能优化

本节摘要：Houdini 性能优化的第一律是测量——开 Performance Monitor 看节点级耗时，再决定动哪里。三大模式覆盖多数场景：降采样（低分辨率调规则）、域限制（只算感兴趣区域）、早剔除（把不需要的数据尽早删掉）。加上缓存分层与内存纪律，构成完整的提速工具箱。

实验：给山体资产做体检

打开 Performance Monitor（Windows 菜单），勾选 Cook 信息，播放/重 cook 一次整条山体流水线。读数典型地呈现"二八分布"：

• Erode 占 60%（大栅格 + 迭代）；
• 散布后的 VEX 邻域计算占 25%（2.1 埋的伏笔）；
• 其余所有节点分摊 15%。

没有这份读数，一切优化都是猜。曾有人把噪声节点反复调参一小时想提速，而监视器显示该节点只占 0.3% 的 cook 时间——这是每天在真实工作室发生的惨剧。

图 8.1-1 优化决策树

三大优化模式

模式一：降采样——用低分辨率调规则

把高度场从 2049 临时切到 513（或给节点加 Bypass），调形态、调规则直到满意，再切回全分辨率一次成型。调参期的任务是确认行为而不是欣赏细节——3.1 的"密度最后定"在这里升级为全流程纪律。

模式二：域限制——只算镜头看到的

近景给全精度，远景砍八成。两类手段：

// 例：只对镜头 60 米内的散布点做昂贵的取向计算
float d = length(v@P - chv('cam_pos'));
if (d < 60) {
    // ……昂贵逻辑（岩石贴地形、变体选择）
} else {
    @pscale = 0.001;   // 或标记为代理实例
}
​

配合按距离分块的 LOD 组，整片山谷的计算量可以降一个量级——第 9 章开放世界的核心技术之一。

模式三：早剔除——数据越早变小越好

在流水线最上游删除确定不需要的东西：高度场先裁剪到项目区域、散布前先按坡度掩码筛面、进 Solver/模拟前先 Blast 掉远处碎块。同样一笔删除，发生在 100 万点上是浪费，发生在 1 万点上是节俭。

缓存分层与内存纪律

• File Cache 是万能止损阀：任何重段后面插一个，锁定后上游随便改。6.2 的产线缓存是它的工程化放大；
• 内存三杀手：未删除的中间属性（Blind data）、全精度显示、忘记 Bypass 的实验节点。Attribute Delete 与节点整洁不是美学，是内存账单；
• 并行友好：Wrangle 默认并行，但涉及全局有序的逻辑（如按编号顺序累积）会强制串行——写 VEX 时保持"每行只依赖自己"的习惯。

⚠️ 常见坑：优化 VEX 的循环体半天，性能监视器里真正的热点是没锁的 Erode 每次交互都在重跑。先测量，一小时省下的可能是几天。

💡 关键直觉：优化的对象不是"代码"，是求值图的形状——哪里在重复求值、哪里数据量可以更小、哪里根本不必算。

本节要点回顾

• Performance Monitor 先行，热点定位是优化的第 0 步；
• 三模式：降采样调规则、域限制省近景、早剔除砍数据；
• File Cache 止损，产线缓存放大同思路；
• 内存靠纪律：删属性、砍显示、清实验节点；
• 优化求值图，不是抠代码行。

机器的时间治好了，下一节治理人的时间：工程化标准。

延伸：热点定位的标准流程

性能优化的第一律是"先测量再动手"，Houdini 的测量工具链完整：节点上的 Cook 时间悬停可见、Performance Monitor 面板录一次整网 cook 得到热点排序、hou.perfMon 可脚本化采集。标准流程：

[热点定位流程]
1. 记录场景全量 cook 基线(总时间 + 内存峰值)
2. Performance Monitor 录制 -> 按 Self Time 排序取前三热点
3. 对每个热点问: 计算必要? 可降采样? 可并行? 可缓存?
4. 只改一项 -> 重测 -> 提交(附前后数据) —— 单变量纪律
​

廕伸：属性与内存的瘦身拳

// 输出审计 Wrangle: 属性体积清单(Detail 模式)
string names[] = detailattribs(0);
foreach (string n; names) {
    int sz = detailattribsize(0, n);
    printf("%-24s %6d bytes/pt\n", n, sz * npoints(0));
}
// 优化动作: Clean 删除临时属性; @Cd 转 @instancecolor;
//         细分前的 P 历史快照用文件引用而非内嵌
​

内存优化的杠杆常在属性而非点数：一个冗余 vector 属性乘以千万点就是数百 MB；字符串属性尤其昂贵，能用整数索引+字典就别存字符串。Cook 优化的三板斧（Edit 节点冻结、Bypass 旁路、OpenCL 切换）配合属性瘦身，典型场景可压掉一半以上内存与三成 cook 时间——数据结构的清洁度就是性能。

再补三条最快的常见提速，供不想做完整 profiling 时的急救：第一，把只算一次的静止分支用 File Cache 或 Display Flag 锁死，防止下游每次 cook 都点燃它；第二，Wrangle 里逐点邻域查询改为先聚合再处理（数组一次取出、批处理后再写回），SIMD 利用率立涨；第三，检查是否有节点在以全分辨率处理最终会被降采样的数据——把 Blur/Resample 提前到计算之前，常常是数量级的节省。三条急救能覆盖多数"忽然变慢"的场景，但根因分析仍要回到热点定位流程，急救不能代替体检。

再补一条分布式场景的性能常识：农场 cook 时，网络文件传输常是隐藏瓶颈——每个工作项读写共享存储的时间可能超过计算本身。对策是输出尽量小（只写下游真正消费的属性与几何）、读写分离（中间产物落本地盘，仅最终结果上传）、以及按空间局部性分组调度（相邻瓦片分到同节点，复用共享缓存）。这些手段的共同思想还是那一句：性能问题多数是数据问题，先审数据流，再谈算得快。