XCode 15打包性能问题排查

Author Avatar
Kanglai Qian 10月 18, 2023

这两天升级了下XCode 15,一开始遇到了Xcode 15 linking errorunary_functionNWEndpoint.hostPort(host: , port: ) crash in Xcode15几个都是小问题。
结果打了个包发现Build时间暴增: 本来单次编译需要1小时左右,现在直接涨到2.5小时还不太够

网上搜了下发现难兄难弟还真不少 Severe performance problems with Xcode 15,那就必须动手研究下这个了。参考Improving the speed of incremental builds使用Build With Timing Summary编译了一发,看了下Report没什么异常——不过引起我注意的是这次clean build压根半小时都不需要来着

暂时没有其它线索的情况下,就找可以对比的例子、看看有没有灵感——问了下楚东那边,升级XCode 15后编译时间从1693.7s降到1512.7s。进一步比较两边环境: 都是macOS Sonoma+XCode 15,我这边是M1 Mac mini(2020),他那边是M2 Pro Mac mini(2023)。
难道氪金的力量真的这么强大嘛一定还有别的蹊跷…

一时间陷入僵局,直到我点开Activity Monitor的时候突然发现华点:

赶紧找楚东对比了下,果然眼前一黑…

为啥这俩的clang一个是Apple一个是Intel…用ps aux|grep clang对比了下发现这个clang的路径完全一致、编译参数也没啥区别。
这时候果断怀疑是不是父进程影响——检查xcodebuild,果然是不一样的架构。

到这一步就可以开始盲猜验证: 试了下在控制台里直接手动调用xcodebuild是Apple架构,但是如果用Python脚本来触发调用就是Intel架构

进一步在网上搜到Conditionally run program using Rosetta 2 on M1 Mac: 在Python脚本里使用arch -arm64 xcodebuild来触发编译,果然也变成Apple架构了orz

最后用新的打包脚本试了下,全量编译的时间从2.5h怒砍到20min! (顺手还补了个-quiet避免日志刷屏)

小结下这次遇到的打包性能问题:

  • 直接使用XCode 15界面进行编译的时候是使用的Apple Arch,这也是为什么我前面Build With Timing Summary测试的时候速度没问题的原因
  • 当使用Python脚本触发命令行打包的时候,可能会不小心用到Intel Arch,带来严重的性能问题,这时候可以使用arch -arm64强制指定成Apple Arch
  • 之前XCode 14.3的时候应该一直是错误使用Intel Arch的情况(虽然我懒得回滚验证了emmm),所以当时的打包时长1h左右 其实也是有问题的,但是性能问题没有XCode 15差别这么大

macOS上像XCode这种本身是Universal Binary的应用, 具体用哪个Arch的机制有点神秘(其实是我懒得继续去翻资料了)。总之还是注意一手,避免性能血亏~

update: 后来和曹哥哥聊了下,发现其实有问题的是Python环境…macOS从Monterey移除内置Python 2.7之后,我应该是从Python官网下了份2.7使用,结果看来是Intel Arch的; 我试了下索性删掉这份Python2,重新从Python官网下一份3.11就已经是Apple Arch了~