Unity调用Python脚本时CMD运行慢于PyCharm的解决方法

云原生阿岚

2026-8-26

问题根因

你测到的耗时差和插值计算本身无关，核心是冷启动开销：

PyCharm运行脚本时会复用常驻的Python后台进程，提前预加载了numpy、scipy这类常用科学计算库，你测到的2ms是跳过了解释器启动、库导入步骤的纯计算耗时。
CMD调用时每次都会启动全新的Python进程，光Python解释器启动（30-50ms）、numpy导入（40-60ms）、scipy.interpolate导入（100-200ms）这三块加起来就有170-310ms，再加上少量初始化计算的时间，刚好落在你测到的200-400ms区间，实际插值计算本身耗时始终在1-2ms级别。
额外核对点：先确认CMD调用的Python解释器和PyCharm所用解释器路径完全一致，避免出现CMD调用了装了大量冗余插件的系统Python、PyCharm用精简虚拟环境的额外差异，分别在两个环境执行import sys; print(sys.executable)即可核对路径。

排查步骤

拆分计时点定位耗时：把原有全局计时拆成多段，分别统计解释器启动到导包前、导包完成、网格初始化完成、插值计算完成四个节点的耗时，就能直接验证上述根因，示例拆分代码：

from time import time
# 节点1：进程启动完成
t1 = time()
import numpy as np
# 节点2：numpy导入完成
t2 = time()
from scipy.interpolate import interpn
# 节点3：scipy插值模块导入完成
t3 = time()

# 固定网格初始化
x = np.linspace(0, 10, 20)
y = np.linspace(0, 10, 20)
z = np.linspace(0, 10, 20)
def value_func(x, y, z):
    return 3*x*x * y + y - z + 100
points = (x, y, z)
values = value_func(*np.meshgrid(*points, indexing='ij'))
# 节点4：固定数据初始化完成
t4 = time()

# 实际插值计算
point_test = np.random.random([100, 3])
result = interpn(points, values, point_test, method='linear')
# 节点5：插值计算完成
t5 = time()

if __name__ == '__main__':
    print(f"导numpy耗时: {t2-t1:.3f}s")
    print(f"导scipy插值模块耗时: {t3-t2:.3f}s")
    print(f"网格初始化耗时: {t4-t3:.3f}s")
    print(f"纯插值计算耗时: {t5-t4:.3f}s")
    print(f"总耗时: {t5-t1:.3f}s")

清理无用代码：你现有代码里t = np.linspace(0, 10, 50)、xt, yt, zt = np.meshgrid(t, t, t)、point = np.array([2.21, 3.12, 1.15])这几行完全没有被后续逻辑使用，属于冗余计算，直接删掉即可。

优化方案

按照收益从高到低排序：

常驻服务模式（收益最高，可将单次调用耗时压到1ms级别）：彻底抛弃每次调用启动新Python进程的模式，写一个轻量Python常驻后台服务，启动时一次性完成库导入、固定插值网格/数值的预加载，之后Unity通过本地TCP、命名管道等方式传入待插值坐标，服务计算完直接返回结果，全程只启动一次Python进程，完全消除冷启动开销，满足高频仿真调用的性能要求。
裁剪依赖降冷启动成本（如果必须保留单次进程调用模式）：scipy是重型库，导包开销占比最高，你用的是规则三维网格线性插值，逻辑非常简单，可以自己实现纯numpy版本的线性插值逻辑，完全去掉scipy依赖，仅保留numpy的情况下冷启动总耗时可以压到50ms以内。如果网格是固定不变的，还可以提前把values数组存为.npy文件，运行时直接np.load读取，省掉网格生成、value计算的时间。
打包优化（收益较低）：用PyInstaller把脚本打包成独立exe，减少Python解释器查找依赖的路径开销，通常能再降10-20ms总耗时，但无法彻底解决冷启动问题，仅作为补充方案。

内容的提问来源于stack exchange，提问作者Eman_Revetahw