Julia JuMP求解优化问题比Python CVXPY慢15倍？求提速技巧

你观测到的15倍速度差，几乎全部来自Julia脚本的冷启动固定开销（进程启动、包加载、JIT即时编译），并非JuMP本身的建模或求解逻辑运行慢。针对这类场景，可以通过以下方法逐步优化：

修正基准测试方式，剔除无关开销 #

• 不要用单次冷启动脚本的总时长衡量运行速度：Julia的JIT编译只在函数首次被调用时触发，针对n=2的极小线性规划问题，求解器本身的运算耗时通常不足1毫秒，脚本运行的绝大部分时间都花在了依赖加载、代码编译上，和求解逻辑无关。正确的测试方式是先在REPL环境中完成所有依赖加载、函数预编译流程，再对实际的建模、求解环节单独计时，通常这部分耗时会比同场景下的CVXPY实现更快。
• 把所有逻辑收敛到类型明确的函数内部：Julia对全局作用域的变量无法做高效的类型推导，会触发大量动态类型检查的编译开销。不要在顶层作用域写变量定义、逻辑运算代码，仅在函数完成定义后，最后在顶层做一次函数调用即可。
• 去掉重复加载的依赖包：不需要同时写using Mosek, MosekTools，using MosekTools本身就会自动加载对应的Mosek后端依赖，重复加载会触发冗余的包初始化流程，拖慢启动速度。

压缩冷启动阶段的固定开销 #

• 启动时关闭用户自定义启动脚本：执行脚本时增加启动参数julia --startup-file=no your_script.jl，跳过对用户目录下.julia/config/startup.jl的读取和执行，减少无关的启动流程开销。
• 减少不必要的临时内存分配：比如把目标函数中的b'*x替换为更高效的内积写法dot(b, x)，避免为临时行矩阵分配内存，虽然对当前这个极小问题影响很小，但是在大规模问题上可以显著降低建模阶段的耗时。
• 对高频运行的脚本使用预编译镜像：通过PackageCompiler把JuMP、常用求解器的依赖提前编译到自定义的Julia系统镜像中，后续启动时直接加载预编译好的代码，跳过首次JIT编译的流程，可以把冷启动总耗时压缩到和Python脚本同量级。

补充说明 #

你当前测试的问题规模极小，固定的进程启动、编译开销在总耗时中占比极高，这类测试结果完全无法代表两个框架在实际大规模优化问题上的性能差异。当问题规模提升到变量数、约束数达到成百上千的量级时，JuMP因为没有Python层的类型转换、问题序列化、规整化的额外开销，整体运行速度通常比同场景下的CVXPY实现快1~2个数量级。

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