为何Python zipapp体积越大运行速度越慢？PDM zipapp启动耗时过长问题排查

我碰到过类似的zipapp启动性能问题，结合你的描述和cProfile的结果，核心问题大概率和Python字节码缓存无法复用有关，下面给你拆解原因、排查方法和优化方案：

为什么zipapp启动会多花0.6秒在编译上？ #

直接从文件系统运行时，Python会把编译好的字节码存在__pycache__目录里，下次启动直接读.pyc文件跳过编译；但zipapp里的模块默认不会生成或复用这些缓存文件——每次启动都得把zip包里所有导入的.py文件重新编译一遍，你的zipapp有25MB大小，包含大量依赖，这部分重复编译的时间就是额外的0.6秒来源。

另外，zip包内的文件读取虽然有索引，但相比本地文件系统还是多了一层zipimport的封装，也会带来一点额外开销，但主要耗时还是在编译上。

怎么定位具体是哪些模块在编译？ #

既然cProfile已经指向compile操作，你可以用这两个方法精准定位：

• 用PYTHONVERBOSE看导入日志：运行zipapp时加上这个环境变量，会输出所有模块的导入和编译细节，能直接看到哪些大模块在拖慢速度：

  PYTHONVERBOSE=2 python your_app.pyz
  

  日志里会有compiling xxx.py的条目，重点看耗时久的那些。
• 写个简单的编译追踪脚本：hook住Python的编译函数，记录每个文件的编译耗时：

  import sys
  import time
  
  original_compile = sys.compile
  
  def traced_compile(source, filename, mode, flags=0, dont_inherit=False, optimize=-1):
      start = time.time()
      result = original_compile(source, filename, mode, flags, dont_inherit, optimize)
      elapsed = time.time() - start
      if elapsed > 0.01:  # 只记录耗时超过10ms的操作
          print(f"编译 {filename} 耗时 {elapsed:.3f}s")
      return result
  
  sys.compile = traced_compile
  
  # 启动你的zipapp
  import runpy
  runpy.run_path("your_app.pyz", run_name="__main__")
  

  运行这个脚本，就能直观看到哪些文件是编译耗时的大户。

优化方案，按优先级排序 #

1. 给zipapp预编译字节码 #

这是最有效的优化，让Python启动时直接读预编译的.pyc，跳过编译步骤：

• 先给你的项目和依赖生成.pyc文件：

  python -m compileall -b your_project_dir
  

  -b参数会把.pyc文件放在和.py同目录下（而不是__pycache__），方便打包进zipapp。
• 用PDM打包时，确保把这些.pyc文件也包含进去。如果PDM的打包工具没有直接支持，可以手动整理文件结构后用python -m zipapp重新打包。

2. 启用编译优化 #

创建zipapp时加上-OO参数，让Python生成优化后的字节码（移除调试信息和文档字符串），能减少编译时间和字节码大小：

python -m zipapp -p "/usr/bin/env python3 -OO" your_app_dir -o your_app.pyz

注意，-OO会删掉所有__doc__属性，要是你的代码依赖文档字符串，就用-O就行。

3. 延迟导入非必要依赖 #

如果帮助页面不需要加载所有依赖，就把那些非核心的依赖改成按需导入——比如只有在执行具体命令时才导入相关模块，这样启动时就不用编译这些模块，能大幅缩短启动时间。

4. 换用PyInstaller（可选） #

要是zipapp的优化还达不到预期，可以试试PyInstaller打包。它会把Python解释器、预编译的字节码和依赖打包成单文件，启动时直接加载字节码，速度通常比zipapp快不少，不过包体积会稍微大一点。

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