XCode 15打包性能问题排查
这两天升级了下XCode 15，一开始遇到了Xcode 15 linking error、unary_function、NWEndpoint.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了~